Description
Troubleshooting approvers in the wrong domain in order to approve workflow steps
Symptoms
- Approvals are stuck
- Hung workflow
- Workflow is not progressing
- Workflow not progressing in domain separated environment
- Workflow hung on activity
- Workflow does not generate a task
- Workflow does not generate approval
Approvers and domains: pre-Eureka
Prior to the Eureka release, it was nececessary to have all workflow versions in the global domain and all users that do approvals had to reside within the domain of their company. If a user inserted a record that initiated a workflow context and that workflow stopped on an approval, but the approval user(s) were not in the same domain, then they would not be able to approve the workflow and it could potentially get stuck. Be sure to follow the procedures outlined in the domain training for administrators carefully when configuring a user instance in a domain separated environment. It will help to avoid this and other pitfalls. The training covers these scenarios in detail and, if the prescribed setup steps are used, workflows will operate correctly.
Approvers and domains: Eureka
As of the Eureka release, it is possible to author or check-out and publish workflows into different domains, including child domains. Workflow contexts are always created in the domain of the user that inserted or updated the current record and they stay in that domain thoughout their lifecyle. They also continue to run as that same user when restarted.
Users that are part of an approval within a workflow will have approval records created for them and they can progress the workflow by approving or rejecting these records.
Users that can view workflow context records may not always have visiblity into the same domain as some or all of the approval users. When they check an approval activity in a running context, they may only see the approval user's sys_id and not their name; this is normal because the domains block the full detail of these users.