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?
- Because the run in user’s context property of a step makes the whole plugin code of that step run on this user’s context.What if we just want to impersonate a user to access some record which isn’t otherwise accessible to the calling user? Yes, in that case, we need explicit user impersonation in the plugin code.
- Impersonation gives the Customer Engagement developer more flexibility to target a particular action in a plugin they would like to run with elevation permissions. The rest of the plugin actions can be run as
There are 2 pre-requisites of user Impersonation:
- The user (impersonator) must have the ActOnBehalfOf privilege or be a member of the PrivUserGroup group in Active Directory.
- Setting the CallerId property of the organization Web service proxy.
User impersonation is very useful if you want to be able to do the following:
- Test the correct implementation of security roles.
- Check which records can be seen by which users if sharing is being used.
- Search for charts or views belonging to different users.
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:
- UserId: User running on-demand workflow
- InitiatingUserId: User running on-demand workflow
And whenever any workflow get trigger automatically
- UserId: workflow owned
- InitiatingUserId: Triggering user
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]
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?
- Because the run in user’s context property of a step makes the whole plugin code of that step run on this user’s context.What if we just want to impersonate a user to access some record which isn’t otherwise accessible to the calling user? Yes, in that case, we need explicit user impersonation in the plugin code.
- Impersonation gives the Customer Engagement developer more flexibility to target a particular action in a plugin they would like to run with elevation permissions. The rest of the plugin actions can be run as
There are 2 pre-requisites of user Impersonation:
- The user (impersonator) must have the ActOnBehalfOf privilege or be a member of the PrivUserGroup group in Active Directory.
- Setting the CallerId property of the organization Web service proxy.
User impersonation is very useful if you want to be able to do the following:
- Test the correct implementation of security roles.
- Check which records can be seen by which users if sharing is being used.
- Search for charts or views belonging to different users.
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:
- UserId: User running on-demand workflow
- InitiatingUserId: User running on-demand workflow
And whenever any workflow get trigger automatically
- UserId: workflow owned
- InitiatingUserId: Triggering user
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
