You’re offline. This is a read only version of the page.
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]
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
*This post is locked for comments
I have the same question (0)
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.
Share
Report
All responses (
Answers (
4,510
