Dynamics 365 – Page 3 – Nishant Rana's Weblog

Understanding Privilege Check and Shared Access in Dataverse / Dynamics 365

Let us understand this with a simple example.

We have the following 2 custom tables having a 1 – N relationship.

Project (1-n) Artefact.

The relationship behavior is Custom with Cascade All for all the actions except Delete.

User 1 is the System Administrator and Test User 1 has the Field Service Admin role but doesn’t have any roles that give him access to the project or artefact table.

We can see the tables are not showing up for Test User 1 in the app unlike User 1 with the System Admin role.

A screenshot of a computer

Description automatically generated

Now let us assign a custom security role – Test Sharing to test user 1 that gives him Organization Level rights on the Project table.

As expected, Test user 1 now has Projects appearing in the app, and as he doesn’t have any rights on the Artefact table, he cannot see it in the form or the app.

Now user 1 shares the Project 1 record with test user 1. Remember we have set Share as Cascade All in the relationship between Project and Artefact.

But still, because the user doesn’t have any privileges on Artefact, it doesn’t appear for Test User 1 on the form as well as the app.

Now let us update the Test Sharing Role and add Read Permissions – User Level for the Artefact table.

Now Test User 1 can see the Artefacts in the related records as well as the App.

We can observe 2 things here –

Although Test User 1 only has User-level Access to the Artefact, he can still see the Artefact records created by User 1, as the parent Project record is shared with Cascade All–Share in the relationship behavior.
And as Test User 1 has only Read access he can only view the artefact records shared.

Here if we update the Test Sharing role to provide Write access at User Level, the user will be able to edit the records.

Also right now if User 1 creates the Project 2 record with the related P2 A2 artefact record, Test User 1 will only have access to the Project 2 record because of Organization Access but not to the P2 A2 artefact record as he has only has the user-level access.

Let us now update the Relationship Behaviour between Project (1-n) Artefact, and set Share to Cascade None.

Let us share the Project 2 record with Test User 1 now through the User 1 account.

As expected even after sharing the Project 2 record, Test User 1 does not have access to the P2 A2 artefact record as we had updated the relationship behavior as Cascade None for Share.

The first check that the user needs to pass is the Privilege Check, which checks if the user has the required privileges for that table before the Shared Access check

A screenshot of a screenshot of a record

Description automatically generated

Also, Check – How access to a record is determined.

Hope it helps..

Advertisements

Fixed – The latitude or longitude for the User record associated with this resource is invalid – Dynamics 365 Field Service /Dataverse

While trying to set the Start Location / End location to the Resource Address for Bookable Resource, we might get the below error

Exception Message: The latitude or longitude for the User record associated with this resource is invalid. Please provide a valid latitude and longitude and then set the start and end location for this resource again.

Here as the error message specifies we need to specify the latitude and longitude value for the corresponding resource type record associated with the Bookable Resource.

In the case of Contact, we can use the Geo Code option, and specify the address to populate the Latitude and Longitude details.

A screenshot of a computer screen

Description automatically generated

In the case of a User record we do not see the Geo Code option so there we can manually specify the values for it.

Now we will be able to update the Start / End Location as Resource Address in our Bookable Resource record, without getting any error.

Get more details on Geocoding

Hope it helps..

Advertisements

Fixed – The plug-in execution failed because no Sandbox Hosts are currently available. Please check that you have a Sandbox server configured and that it is running – Dataverse / Dynamics 365

Recently we were bulk updating our records, which would trigger an asynchronous plugin registered on its update. We were using the wonderful Bulk Data Updater (XrmToolBox) plugin for it. We realized if we are updating too many records at once say e.g. 100 Batch Size (total 5K records to be processed), we are getting below exception.

The plug-in execution failed because no Sandbox Hosts are currently available. Please check that you have a Sandbox server configured and that it is running.System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: The plug-in execution failed because no Sandbox Hosts are currently available. Please check that you have a Sandbox server configured and that it is running. Microsoft.Xrm.RemotePlugin.Grpc.ExceptionHandlers.SandboxFabricHostCommunicationException: Error communicating with Sandbox Host

We than updated the Execution settings to process with a Batch Size of 5 with an interval of 60 seconds. This fixed the issue for us.

Also, check –

The plug-in execution failed because the Sandbox Worker process crashed. This is typically due to an error in the plug-in code – Dataverse / Dynamics 365

The plug-in execution failed because no Sandbox Hosts are currently available. Please check that you have a Sandbox server configured and that it is running.

Hope it helps..

Fixed – Web resource method does not exist: OnLoad error in Work Order, Work Order Service task, and other forms in Dynamics 365 Field Service

Recently we started getting the below error on the form load of the Work Order Service Task record, that also only in specific environments, and there was no changes made there.

Error Details: Event Name: onload Function Name: OnLoad Web Resource Name: msdyn_/WorkOrderServiceTask/WorkOrderServiceTask.js Solution Name: msdyn_FieldService_patch_update Publisher Name: microsoftdynamics

A screenshot of a computer error

Description automatically generated

From the error message also it was clear it was the error in the out-of-the-box javascript.

On raising the Microsoft Support Ticket, we were immediately informed that it was because of a change in the function definitions in the .js files along with its associated handlers which was done to prevent object definition collisions in the web resources.

This applied to forms of the below tables

Work Order (msdyn_workorder)
Work Order Service Task (msdyn_workorderservicetask)
Work Order Product (msdyn_workorderproduct)
Work Order Service (msdyn_workorderservice)
Knowledge Article (knowledgearticle)

And below are the changes required to be done.

Work Order (msdyn_workorder)
- Library value: msdyn_/WorkOrder/WorkOrderExperience.Library.js
  EITHER:
  - Incorrect function: onLoadLightForm
  - Correct function: WorkOrderExperience.Library.onLoadLightForm
    OR
  - Incorrect function: onLoad
  - Correct function: WorkOrderExperience.Library.onLoad

Work Order Service Task (msdyn_workorderservicetask)
- Incorrect
  - Library value: msdyn_/WorkOrderServiceTask/WorkOrderServiceTask.js
  - Function value: OnLoad
- Correct
  - Library value: msdyn_/WorkOrderServiceTask/WorkOrderServiceTaskGrid.js
  - Function value: WorkOrderServiceTaskGrid.OnLoad

Work Order Product (msdyn_workorderproduct)

Library: msdyn_/WorkOrderProduct/WorkOrderProductGrid.js
- Incorrect function: OnLoad
- Correct function: WorkOrderProductGrid.OnLoad

Work Order Service (msdyn_workorderservice)

Library: msdyn_/WorkOrderService/WorkOrderServiceGrid.js
- Incorrect function: OnLoad
- Correct function: WorkOrderServiceGrid.OnLoad

Library: msdyn_/KnowledgeArticle/KnowledgeArticleWorkOrderRelationship.js
- Incorrect function: OnSave
- Correct function: KnowledgeArticleWorkOrderRelationship.OnSave

We applied the change to the other forms also, which fixed the error for us.

Hope it helps..

Advertisements

Use Solution Health Hub to troubleshoot issues in Dynamics 365 Apps (Sales, Marketing, Field Service, Customer Service..)

Using Solution Health Hub we can validate the environment’s configuration, which might get modified over time, to get an idea about the state of that environment and detect and resolve any issues. Solution Health Hub enables rules-based validations, which we can run periodically or manually if we encounter any issues. The rules also get triggered automatically when solutions are installed or updated by Microsoft. The rules check if some of the required processes are disabled or owned by a disabled user, if some of the required web resources are missing, if certain plugin steps are not active etc.

Let us open the Solution Health Hub app and see it in action.

We can see the Rule Sets created specific to different areas (app) like Sales, Marketing, Customer Service, etc.

For an environment where Field Service is configured, we can see the following rule sets.

Let us open the Field Service Rule Set and see the rules defined for it.

We can see around 31 rules defined for Field Service

For Sales, we can see around 6 rules.

Around 22 rules for Customer Service.

And around 5 rules for Marketing

To run the Rules, we need to create a new Analysis Job record and select the corresponding Rule Set.

A summary of rule-set executions will be shown in a few seconds. (runs asynchronously)

We can see one of the rules failed.

Opening the record, we can see the details.

Back in our solution, we can see the steps in the disabled state.

Back in our Analysis Job, let us select the failed rule and click on Resolve.

We can see the message “Resolution is completed.” and the rule passed.

Back inside our solution, we can also see the status as On for those steps.

Now let us run an analysis job for Field Service

On opening the record, we can see the user for which the roles are missing.

For Field Service, we can see an out-of-the-box cloud flow that runs at midnight on Saturdays to trigger the analysis job for the Field Service Rule Set.

And sends the In-app notifications.

Now if a rule fails, we can get the in-app notifications, e.g. we had set the Service Account field as optional on the Work Order form.

That caused the below rule to fail.

This also sent the notification in the app.

More details on it – https://powerusers.microsoft.com/t5/Power-Apps-Community-Blog/In-App-Notifications-on-concerns-related-to-Solution-Health-and/ba-p/1287680

Also, for each of the rules, we can see a corresponding Action that holds the logic.

Hope it helps..

Advertisements

Transitioning from Unmanaged to Managed Solution (Dynamics 365 / Dataverse)

Microsoft has always recommended managed solution(s), apart from the some of benefits that managed solutions offer over unmanaged, Microsoft is also adding features to the managed solution, making it easy for teams to adopt and transition to Managed solutions, like focusing on making the solution import faster and adding ALM-specific features to it.

Let us take a simple example to see it working –

Suppose we have 2 environments, a Test and a Managed environment.

The test environment has 2 unmanaged solutions from different publisher that is already deployed to the target environment as unmanaged.

Source –

Target –

Ideally, we should be creating 2 copies of production environments, one for creating the new unmanaged solution (s) containing the components to be converted to managed and the other environment where the unmanaged solution (s) will be converted to managed and will be used for testing and validation.

Ref – Dynamics 365 FastTrack Architecture Insights – ALM Transitioning from Unmanaged to Managed Solutions

https://learn.microsoft.com/en-us/shows/dynamics-365-fasttrack-architecture-insights/alm-transitioning-from-unmanaged-to-managed-solutions

Now let us create a new unmanaged solution in the source environment that will combine the components we have in Pub 1 and Pub 2 unmanaged solutions.

Here we can use the wonderful XrmToolBox plugin – Solutions Components Mover.

https://prajapatiamit.medium.com/move-the-components-between-customization-solutions-in-d365-customer-engagement-crm-solution-8f17a1fafb2b

Select source solutions and the target solution (combined) in our case, and click on Copy Components.

Here we have selected all the component types.

Back in our TestEnv, we can see the components of the solution added from Pub 1 and Pub 2 solutions to the combined solution.

Let us export the combined solution as managed.

The other way to create the combined solution would be to “Include all objects” for unmanaged components like custom tables. For managed components, like out-of-the-box tables lead, contact, case, etc, we’d only select the components customized.

Run the below command, to connect to the destination (managedenv) environment.

https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/auth#pac-auth-create

Run the below command, to convert the unmanaged solution to managed.

https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/solution#–convert-to-managed–cm

We can see the managed solution imported successfully to our target environment.

For quick reference –

Unmanaged	Managed
Unmanaged solutions are intended to be used in the development environment.	Managed solutions are intended to be distributed and installed.
Unmanaged solutions can be exported either as managed or unmanaged.	Managed solutions cannot be exported
Components can be directly edited within an unmanaged solution.	Components inside the managed solutions cannot be edited directly. Editing can only be done in the corresponding unmanaged solution or an additional unmanaged solution in dev and then exported and imported as managed in the target environment.
The unmanaged solution can be seen as the source code	A managed solution can be seen as a compiled code.
Deleting an unmanaged solution only deletes the solution container, all unmanaged customizations remain in effect and are applied to the default solution of the environment	Deleting a managed solution removes the customizations from the environment.

Benefits	Benefits
Unmanaged solutions allow for real-time customization directly within the environment.	The managed solution secures the solution components in the environment, by restricting the user from making changes or removing components from it.
Developers can make changes on the fly without the need for importing/exporting solutions	Ability to uninstall/roll back. In case of issues or undesired changes, managed solutions make it easier to roll back to a previous version. This can be crucial for maintaining system stability and ensuring minimal disruption to ongoing operations
	The managed solution supports layering allowing multiple solutions to be installed simultaneously without conflicts.
	Clearly defined component ownership in the case of multiple publishers/solutions.
	Improved solution import performance with reduced performance impact on the environment.