Dynamics 365 – Page 3 – Nishant Rana's Weblog

Using AI to Build Tables and Fields in Dynamics 365 with PowerMakerAI’s AI Entity Builder & Visualizer (Tool Showcase)

Recently, I came across a very interesting tool called PowerMakerAI, developed by a fellow community member. I felt it’s worth sharing here because it directly helps us in one of the most common and time-consuming tasks — creating tables and fields in Dynamics 365.

Creating custom entities and fields in Microsoft Dynamics 365 is essential — but let’s be honest, it’s often tedious and time-consuming. Navigating through multiple forms, selecting field types, defining metadata, and ensuring consistency takes significant effort, especially for complex data models.

That’s where PowerMakerAI’s AI Entity Builder with Visualizer comes in.

🎯 What is the AI Entity Builder?

The AI Entity Builder is a natural language-powered tool that lets you create complete entity definitions by simply describing what you need — just like talking to a junior developer.

Instead of clicking through menus or filling out field properties manually, you can say:

“Create an entity called ‘Customer Feedback’ with fields for Name, Email, Rating (1-5), Comments, and Submitted On.”

PowerMakerAI understands your intent and instantly generates a complete schema, including:

Logical names
Display names
Field data types
Required levels
Primary field selection
Relationship suggestions (coming soon)

A screenshot of a computer

AI-generated content may be incorrect.

👁️ Visualizer: See What You’re Building — Instantly

One of the most powerful additions is the interactive schema visualizer.

Once your entity is generated, the visualizer shows you:

All attributes in a structured format
Field types (text, number, option set, date, etc.)
Required vs optional fields
Entity-level metadata
[Coming Soon] Relationships with other entities

You can drag, zoom, and explore your schema visually — no need to switch back and forth between the Dynamics UI and your schema documentation.

🧠 How It Works (Under the Hood)

PowerMakerAI uses a combination of:

Natural Language Understanding (NLU): To detect intent, field names, data types, and relationships.
CRM Schema Intelligence: Built-in logic that maps certain keywords to CRM field types (e.g., “status” = OptionSet, “submitted on” = DateTime).
Dynamic Validations: Prevents common issues like duplicate logical names or unsupported characters.

It then presents the results in human-readable formats.

⚡ Benefits

🕒 Save Hours: No more manual field creation
💬 Speak Requirements: Great for functional consultants too
📦 Deployment-Ready: Export and import with minimal edits
🧩 Visual Confidence: Know what you’re building before you build it
👥 Perfect for Teams: Let non-technical users define schema, and devs just approve and deploy

🧪 Example Use Case

A marketing team wants a “Campaign Response” entity. Instead of submitting a spec document and waiting for dev time, they use PowerMakerAI:

“Create a Campaign Response entity with Contact, Campaign Name, Response Type (dropdown), Notes, and Created On.”

💡 In under 30 seconds, the entire entity is ready, visualized, and exportable.

🚧 Coming Soon

We’re just getting started. Upcoming features include:

🔁 Relationship suggestions (1:N, N:N)
✅ Auto-validation for solution compatibility
📤 One-click push to your CRM environment
🔄 Integration with PowerMakerAI’s chatbot for conversational updates

💬 Try It Yourself

You can explore PowerMakerAI yourself here: https://powermakerai.com. The creators are currently offering it free during beta.

Advertisements

Fixing Date Shift Issue After Changing DateOnly Field from Time Zone Independent to User Local – Dataverse / Dynamics 365

In our Dataverse environment, we had a field named custom_sampledate configured as a DateOnly type with User Local behavior. At some point, we changed its behavior to Time Zone Independent, assuming it would prevent confusion across time zones.

At first glance, everything seemed fine. But over time, users in time zones like New Zealand (NZ) started reporting an issue: for older records created before the change, the dates were now showing up as one day earlier than what they had originally entered.

This was because, when we changed the field’s behavior from User Local to Time Zone Independent, Dataverse stopped interpreting the date based on the user’s local time zone. Instead, it began treating the stored value exactly as-is, which caused trouble for values that were originally entered as User Local, especially from users in forward time zones like NZ.

Dataverse stores DateOnly fields as a datetime behind the scenes, with the time part set to 00:00:00.000. The behavior setting (User Local vs. Time Zone Independent) affects how this raw value is interpreted and displayed. Before the behavior was changed, NZ users (UTC+13/UTC+12) were entering dates into a User Local field. Dataverse automatically converted their local midnight time to UTC when storing it.

For example:

A NZ user enters 2025-04-03
Dataverse stores it as 2025-04-02 11:00:00 UTC

Later, when the field behavior was switched to Time Zone Independent, that same stored value was no longer adjusted for the user’s time zone. It got displayed as is as 2025-04-02 which was one day earlier than intended.

However, the new records entered after the change didn’t show the issue, because after the behavior was set to Time Zone Independent, any newly entered values were saved and displayed exactly as the user typed them—without conversion.

To correct this mismatch without losing data, we followed the below approach:

Created a temporary DateOnly field named custom_sampledate_temp, set to Time Zone Independent behavior.
Copied all values from the existing custom_sampledate field into custom_sampledate_temp.
Deleted the original custom_sampledate field (after backups).
Recreated custom_sampledate with the same schema name, but set it back to User Local behavior.
Copied data back from the temp field into the new custom_sampledate field.
Deleted the temp field after verification.

Also check for more information – https://temmyraharjo.wordpress.com/2024/05/18/dataverse-update-time-zone-adjustment-from-time-zone-independent-to-user-local-and-date-time-behavior/

Changing a DateOnly field from User Local to Time Zone Independent, might look harmless—but it can cause subtle issues, especially across global teams. We need to careful before we make this change, as apart from UI this could result changing the JavaScript, Cloud Flows and Plugins where we have used that field to reflect correct date.

Hope it helps..

Advertisements

Fix – The FnO Integration solution install failed. HCMScheduling and HCMSchedulingAnchor solutions must be installed. See Field Service documentation for details (Dynamics 365 Field Service)

While trying to install Finance and Operations from Field Service Settings, we might encounter the following error.

“The FnO Integration solution install failed. Please contact your system administrator. HCMScheduling and HCMSchedulingAnchor solutions must be installed. See Field Service documentation for details.”

To fix it, we need to install the “Dynamics 365 Human Resources integration to URS” app.

However, while trying to install Dynamics 365 HR Integration to URS app, we got the following error –

HCMSchedulingAnchor

NotProvided

Unable to establish connection using data source: ‘Finance and Operations Virtual Data Source Configuration’. Failed to sync entity metadata. Ensure the data source is configured properly.

The fix was to install the Finance and Operations Virtual Entity app first.

A close up of words

AI-generated content may be incorrect.

After installing Finance and Operations Virtual Entity, we were able to install the Dynamics 365 HR Integration to URS app successfully.

That finally allowed us to install the FnO Integration (msdyn_FieldServiceFnOIntegration) in our Environment.

Hope it helps..

Advertisements

Using Form fill Assist Toolbar to streamline data entry in Power Apps

We tried the AI Form Filling Assistance feature in model-driven Power Apps and found it very helpful. One part that we liked the most was the toolbar and file (preview). This makes it much easier to fill forms using information from uploaded documents.

To enable this feature, go to:

Environment → Settings → Features → Form fill assist toolbar (AI Form Fill Assistance)

Once enabled, we can simply upload or drag and drop a file — like a PDF, Word document, or image — and the assistant will read the file and suggest values for different form fields.

When we upload / drop a file like a PDF, Word, or image, the assistant reads the file and gives us suggestions to fill the form.

For example, if we upload the following file:

A close-up of a foreign passport

AI-generated content may be incorrect.

We can see that the assistant picks up values like First Name, Last Name, City, and Country, and populates them into our contact record.

Either we can accept all the suggestions using the Accept suggestions button on the tool bar or can select the suggested value for the individual fields by clicking yes next to it.

The assistant works at the tab level. For example, if we switch to the Details tab and upload the same image again, we might see fields like Birthday get populated — depending on what data is available and which fields are present in that tab.

The different file types supported are – .txt, .docx, .csv, .pdf, .png, .jpg, .jpeg, .bmp.

Let us now try uploading the below text file.

We can see it picking the first record and populating the details on the form.

This makes it simple and fast to enter data — especially when we are working with leads, contacts, or records that are usually based on data from documents or scanned forms.

Get more information

Hope it helps..

Advertisements

How We Reclaimed Storage from the WebResourceBase Table in Dataverse

While reviewing our Dataverse environment’s storage usage, we noticed something surprising—over 13 GB of our file capacity was being consumed by the WebResourceBase table alone. This table typically stores JavaScript files, HTML web resources, images, and other files tied to customizations in Dynamics 365. However, the volume was unexpectedly high, prompting us to investigate further.

We started by examining the capacity usage charts available under:

Power Platform Admin Center > Resources > Capacity > File Usage

It was evident that the WebResourceBase table was consistently occupying around 13,027 MB (13 GB), far more than any other table.

Realizing that this wasn’t just normal customization data, we raised a support request with Microsoft to understand what was happening behind the scenes.

After a quick investigation, Microsoft Support responded with the following:

“Upon review, we have found that the WebResourceBase table is indeed occupying a significant amount of storage—13.027 GB. There are instances of ‘orphaned’ WebResourceBase records, which can occur due to solution uninstalls or as leftover artifacts from other entities that depend on WebResources. To address this issue, we can run a script to remove these orphaned web resources, which will help in reducing the storage used in your environment.”

These “orphaned” records are essentially detached or unused web resources—files that are no longer tied to any solution or customization but remain in storage. They commonly appear in environments where unmanaged solutions are frequently installed and removed.

Upon our approval, Microsoft executed a backend script to safely identify and remove these orphaned entries.

Post-Cleanup Results –

Before: 13,027 MB

After: 10009MB

Recovered: 3,018 MB (~3 GB)

This led to around a 24 percent reduction in the file capacity used by the WebResourceBase table.

Microsoft also confirmed that no further reduction was possible at this time—the remaining content is either actively referenced or structurally required by the platform.

Hope it helps..

Advertisements

Handling Unexpected Lookup Auto-Population in Quick Create Forms (Dynamics 365)

Recently, we had a requirement to track the Current and Previous contracts for a Contact in our Dataverse environment. To achieve this, we created two separate N:1 relationships between the Contact and Contract tables

custom_currentcontractid → Contact’s Current Contract
custom_previouscontractid → Contact’s Previous Contract

So far, so good.

Soon after, we noticed a strange issue: “When creating a Contact from a Contract record (via the Quick Create form), both Current Contract and Previous Contract fields were being automatically populated — with the same Contract record”. This was unexpected, especially since neither field was present on the Quick Create form!

After saving and closing, when we open the record, we can see both the lookup auto-populated with the contract record in context.

A screenshot of a test

AI-generated content may be incorrect.

On adding these lookups in the Quick Create form, we can see that Dataverse is auto-populating it with the contract in context.

A screenshot of a contact page

AI-generated content may be incorrect.

When we open a Quick Create form from a record (in our case, from a Contract), Dataverse passes the entity reference context to the Quick Create form. And here’s the catch, If the target entity (Contact) has multiple lookups to the source entity (Contract), Dataverse tries to populate them all.

This behavior is based on relationship metadata, not on what’s visible on the form. So even though we didn’t include the Current Active Contract or Previous Contract on the Quick Create form, Dataverse filled both with the same value.

If we have the fields on the quick create form we can make use of JavaScript on the onload to clear the values.

function clearBothContractLookups(executionContext) {
    var formContext = executionContext.getFormContext();
    
    // Check if in Quick Create mode (formType = 1)
    if (formContext.ui.getFormType() === 1) { 
        var parentRecord = formContext.data.entity.getEntityReference();
        
        // If opened from a Contact, clear BOTH lookups
        if (parentRecord && parentRecord.entityType === "contact") {
            // Clear Current Contract
            if (formContext.getAttribute("new_currentcontract")) {
                formContext.getAttribute("new_currentcontract").setValue(null);
            }
            
            // Clear Previous Contract
            if (formContext.getAttribute("new_previouscontract")) {
                formContext.getAttribute("new_previouscontract").setValue(null);
            }
        }
    }
}

However, like in our case as we did not have these fields on the quick create form, and we didn’t want to have these populated during the creation of the Contract, as these fields were supposed to be populated later, we wrote a Pre-Create Plugin on Pre Operation for it.

public class ClearBothContractLookups : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
        
        if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is Entity)
        {
            Entity contact = (Entity)context.InputParameters["Target"];
            
               // Clear BOTH fields if they exist
                if (contact.Contains("new_currentcontract"))
                    contact["new_currentcontract"] = null;
                
                if (contact.Contains("new_previouscontract"))
                    contact["new_previouscontract"] = null;

              // or remove them from the input parameters 
                  contact.Attributes.Remove("new_currentcontract");
                  contact.Attributes.Remove("new_previouscontract");

            }
        }
    }
}

Hope it helps..

Advertisements