2 minute timeout issue when running a custom workflow from Dynamics 365

Question

We are running a workflow triggered by a Job. The workflow runs custom workflow activity developed in C#.

The code reads between 2200 to 10000 records after processing it updates certain fields in the Entity. Of course this process times out when the custom workflow activity plugin is deployed in sandbox mode but works when the plugin is deployed in non sandbox mode (None).

Reason being that the client does not want to give us a user account that resides in the Deployment Administrator group that is required for the user deploying the plugin in non sandboxed mode.

Is there another way of deploying a plugin to the Dynamics 365 organization in non sandboxed mode?

Answer 1

The documentation confirms the requirement for the user to be in the Deployment Administrators group.

Perhaps the client could create an account that they control and you walk them through registering the plugin under that account.

For the long-term it's good to consider the possibility that the on-prem instance may someday move into the cloud, where non-sandboxed registration is impossible. (While that might change in the future, Microsoft has been pushing everything toward Azure, so I personally wouldn't bet on it).

In light of that, it might make sense to consider re-architecting the functionality to operate in a way that can work within the sandbox's limitations. For example, you could create an Azure-aware plugin that sends the context to an Azure endpoint, when it turn processes the records outside of any sandbox restrictions. Of course this requires an Azure account, and being on-prem could complicate the Azure resources connecting back into Dynamics.

Although it definitely would be a "hack", you could have the first run of the workflow query for all the ids you need to process and then start processing them. When the 2-minute timeout approaches, you could save the list of unprocessed records to a text field or as an XML web resource. A workflow can call itself up to 7 times before the infinite loop detection kicks in, so you can trigger the workflow again, retrieve the list of unprocessed records, and resume processing. This is quite complex, and assumes that all the processing can always be done in 14 minutes (including shutdown/resume time). The preferred solution would be to use Azure, but if there's no other option, this could work.

And, if you want to get even hackier with the resume capabilities, there's always the old Bulk Deletion trick.