An organization implements a credit check as a custom process action whose logic lives entirely in a plug-in registered on the action. Administrators have twice deactivated the action by mistake, and other teams have registered synchronous steps that changed its behavior. The developer wants a code-first replacement that avoids both problems. What should the developer build?

Custom APIs are Microsoft's code-first alternative to custom process actions. The main operation logic is linked through the plug-in type on the custom API, and AllowedCustomProcessingStepType controls whether others may register synchronous or asynchronous steps, so setting it to None or Async Only prevents other teams from altering or cancelling the operation. A custom API record is not a workflow and cannot be deactivated from the process list, which removes the accidental-deactivation risk. Custom APIs also support functions, private messages and execute privileges, which custom process actions lack. Building a new custom process action with logic in the workflow definition keeps both weaknesses: it can still be deactivated in the user interface and still accepts third-party synchronous steps unless an extra managed property is set. A real-time workflow with a custom workflow activity is triggered by row changes rather than invoked as a message, changing the integration contract, and it remains a deactivatable process. A custom API without a plug-in type but with the logic in a PreOperation step depends on allowing synchronous steps on the message, which reopens the door the team wants closed. Exam caveat: the processing step type cannot be changed after the custom API is created. Operational check: call the new custom API, then confirm that attempts to register a synchronous step on its message are rejected.