Tips

You open a view on a custom table and get “The entity name doesn’t exist”. Most likely the view has an object type code (ObjectTypeCode) stored that doesn’t belong to this environment. It tends to happen when you move solutions between environments, because custom tables don’t necessarily get the same code in each one. Standard tables like account or contact won’t give you this problem, since their code never changes.

To fix it, first get the real ObjectTypeCode of the table in your environment:

https://YOUR-ENV.crm4.dynamics.com/api/data/v9.2/EntityDefinitions?$select=LogicalName,ObjectTypeCode&$filter=LogicalName eq 'table_name'

Then open XrmToolBox → View Designer, load the table and, in each view, edit the XML to replace the old number in the object attribute with the one you just copied. Save, publish, and the view should open normally again.

You start coding and halfway through you notice you’re on the wrong branch, usually main. There’s no need to copy files around by hand.

If the branch already exists, stash the changes, switch and bring them back:

git stash
git checkout other-branch
git stash pop

If the branch doesn’t exist yet it’s even simpler. Uncommitted changes come along when you create a branch, so you can skip stash entirely:

git switch -c my-new-branch

git stash pop may give you conflicts if the other branch changed the same files. Just resolve them like any other conflict. The stash isn’t dropped until it applies cleanly, so nothing gets lost, and git stash list will show it to you.

Every plugin starts the same way. You need the context, the tracing service, the organization service and the record that fired the plugin (Target). This is the boilerplate I always copy:

public void Execute(IServiceProvider serviceProvider)
{
    var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
    var tracing = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
    var factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
    var service = factory.CreateOrganizationService(context.UserId);
 
    if (!context.InputParameters.Contains("Target") || !(context.InputParameters["Target"] is Entity target))
        return;
 
    tracing.Trace("Plugin executed on {0} {1}", target.LogicalName, target.Id);
    // Your logic here
}

CreateOrganizationService(context.UserId) gives you a service with the permissions of the user who triggered the action. Pass null and it runs as SYSTEM, bypassing security, which I only do when there’s really no other way.

The type check on Target is there for a reason too. On a Delete you get an EntityReference rather than an Entity, so casting it straight to Entity would make the plugin fail.

Finally, on an Update the Target only contains the columns that changed. If you need to read others, register a pre-image on the step.

You can’t set a lookup field by just passing it a GUID. It expects an array containing an object with id, name and entityType, so I usually keep a small helper around to avoid writing it out every time:

function setLookup(executionContext, fieldName, id, name, entityType) {
  const formContext = executionContext.getFormContext();
  formContext.getAttribute(fieldName).setValue([
    { id: id, name: name, entityType: entityType },
  ]);
}
 
// Example: set the parent account
setLookup(executionContext, "parentcustomerid", "00000000-0000-0000-0000-000000000000", "Axazure", "account");

entityType takes the logical name of the table (account, contact), not the display name. name is the text shown on the form, and if you leave it out the field looks empty until you save.

Customer lookups such as customerid or parentcustomerid need a bit more care. They accept several tables, and if entityType isn’t the right one the save fails.

To clear the field, use formContext.getAttribute(fieldName).setValue(null).

The Power Pages Web API (/_api/...) doesn’t work with any table until you enable it yourself. You need two things, the site settings and the table permissions.

In Site Settings, add these two entries:

Replace account with your table’s logical name. fields is a comma separated list of the columns that can be read and written. You can use * to include all of them, but I’d rather keep it to the ones I actually use.

Then, under Table Permissions, create a permission for the table with the privileges you need (read, create, write) and the right access type, whether that’s global, contact or account. Assign it to the web role of the users who will call the API.

If it still doesn’t respond after all that, it’s probably the cache not having picked up the changes yet. As an administrator you can force a refresh from /_services/about.