Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 1 PlanDynamics 365 release plan for the 2022 release wave 1 describes all new features releasing from April 2022 through September 2022.
2022 release wave 1 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
As the name suggests, impersonation in Customer Engagement means acting on behalf of another user.
Though impersonation is not available from front-end Customer Engagement login, it is possible to impersonate a different user while making API call to Dynamics 365 Customer Engagement (Customer Engagement).
The plugin registration tool of MS Customer Engagement already have an option to define the calling user for any plugin step:
Then why we need user impersonation explicitly in plugin code?
There are 2 pre-requisites of user Impersonation:
User impersonation is very useful if you want to be able to do the following:
ex 1: Let’s say you have a complex scenario where you shared a record using automatic sharing in your code to certain users. Not to test whether these users can access the record properly is a time-consuming task. But using user impersonation in.Net code you can write a test suite where you can test the access to this record for a set of a user to whom you shared.
So you see how easy it is to do something using user impersonation whereas it would have taken time to do the same thing from the front end.
To impersonate a user, we have to set the CallerId property on an instance of OrganizationServiceProxy before calling the service’s Web methods.
ex 2: You have to give an on-demand custom workflow to users where the custom workflow is doing tasks which is out of the privilege of the user executing the workflow.
The problem is whenever we run the workflow on-demand, we get the UserId and IntiatingUserId as follows:
And whenever any workflow get trigger automatically
So in this scenario, out of the box, we can never get the user having sufficient permission as context user for workflow. So to overcome the problem, we can pass the user-id of some admin(the user having sufficient permission) in code as shown below:
Function to get user-id by full name [Continue Reading]
Function to get user-id by full name
Plugin tool provides "run as" user identity.. its static and will not change based on situation. However if you use impersonation using code then you will have full control when to invoke the code based on business scenario. Be aware (as per my understanding) code impersonation will not work if both users are not having permissions on the resource they are going to access.
Hope this helps.
Business Applications communities