Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
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