A synchronous PostOperation plug-in on the expense report Create message creates a related approval record. It works for administrators, but salespeople receive an access-denied error when saving expense reports. Policy states that approval records must always be created, even though salespeople have no privileges on the approval table. What should the developer change?

A service created with context.UserId runs every operation under that user's privileges, so when salespeople lack create rights on the approval table the plug-in's create fails and the whole save rolls back. Because policy requires the approval to exist regardless of the submitter's privileges, the creation should use a service from CreateOrganizationService(null), which runs as the SYSTEM user. The code can still use the user-context service for operations that should respect the caller's security, making the elevation deliberate and limited to one operation. Granting salespeople create privilege on the approval table would let them create or tamper with approvals directly through any client, which violates the requirement that they have no privileges there. Switching to asynchronous mode does not elevate privileges; asynchronous steps still run in the context configured on the step, and the approval would be created after the save, weakening the guarantee. Suppressing the exception lets the expense report save without its approval, which breaks the policy rather than satisfying it. Exam caveat: system-context code bypasses security checks, so validate inputs before writing and avoid exposing arbitrary data through it. Operational check: save an expense report as a salesperson and confirm the report and its approval both exist, with the approval created by the system account.