A plug-in on the Create of a service request must create a follow-up task. Business rules require that the task creation respect the security role of the user who submitted the request, so it fails if that user cannot create tasks. How should the plug-in obtain its IOrganizationService instance?

Inside a plug-in, IOrganizationServiceFactory.CreateOrganizationService returns a service whose operations run in the security context of the user ID passed in. Passing context.UserId, which is the user the step runs as, makes the task creation subject to that user's security roles, so it fails when the user lacks the create privilege on task, which is the required behavior. If the step is registered to impersonate another user, UserId reflects that setting, while InitiatingUserId always identifies the person who started the request. Passing null returns a service that runs as the SYSTEM user, which bypasses the caller's privileges; it is the right choice when the operation must succeed regardless of the user, but it contradicts this requirement. Creating a ServiceClient with a connection string inside a plug-in is not supported in the sandbox for Dataverse operations, would require stored credentials, and would run as the account in the connection string rather than the caller. Restricting InitiatingUserId to asynchronous steps confuses the property with a mode setting; both identifiers are available in both modes, and the choice depends on whose privileges should apply. Exam caveat: the Run in User's Context setting on the step changes UserId. Operational check: submit a request as a user without task create privilege and confirm the plug-in fails with a privilege error.