If you are writing custom workflows and calling CRM services, you are probably familiar with the following code which creates a service with system administrator access to all data. ( true = administrator access )
ICrmService service = context.CreateCrmService(true);
You may have noticed that any entities created by a custom workflow using this administrator access default to being created and owned by the account that your Microsoft CRM Asynchronous Processing Service runs as.
This has some trickle down depending on the account your async service is using.
For example if you are using the Local System Account which “typically” does not have a CRM user account dedicated to it, there are some things that you won’t have permission to do.
For example the Local System account doesn’t have permission to send an email and the following will fail even with a service having administrator access.
var sendRequest = new SendEmailRequest
EmailId = emailId,
IssueSend = true,
TrackingToken = String.Empty
This will give you the following SoapException:
<description>An unexpected error occurred.</description>
ICrmService sendEmailService = context.CreateCrmService(false);
You could also use a CRM user CAL and create a CRM user for the account your async service runs as.
The important thing to realize is that any service request that requires user configuration in order to function beyond security role permissions will be dependent on whether there is a CRM user assigned to the account the acync service is running under and how that CRM user is configured. For example: whether the email access type is E-mail Router.