A plug-in step is registered to run in the context of a dedicated integration user rather than the calling user. An audit row that the plug-in writes must record the human who saved the original record. Which execution context property gives that person's ID?
Select an answer to reveal the explanation.
Short Explanation
When a plug-in borrows someone else's badge, you still want to know who walked in the door. UserId is the badge the step is using; InitiatingUserId is the person who actually started it. Don't mix them up, or your audit trail will blame the integration account.
Full Explanation
The execution context exposes two user identifiers. UserId is the user in whose context the plug-in executes, which follows the step's Run in User's Context setting or impersonation by the caller. InitiatingUserId is the user who initiated the operation, the person who saved the record, regardless of any impersonation configured for the step. When the step runs as a dedicated integration user, UserId holds the integration user and InitiatingUserId still holds the human, so the audit row should use InitiatingUserId. Treating UserId as always being the human ignores the step's run-as configuration; in this scenario it returns the integration user. PrimaryEntityId is the ID of the row the operation targets, not a user, unless the operation happens to be on the systemuser table. BusinessUnitId identifies the business unit of the user whose context the step runs in, which does not identify an individual and would point to the integration user's unit. Exam caveat: an organization service created with the factory's CreateOrganizationService method uses the identity passed in, so writing as InitiatingUserId and writing as UserId give different auditing results. Operational check: save a test record as a named user, log both IDs in the trace log, and confirm InitiatingUserId matches the named user.