One of the most common issues I see with workflow issues is poor design in Assignment type and Completion policy. 

Assignment type is a critical decision to ensure only users should be able to complete the workflow step, typically an approval, and often determined based on current needs rather than future changes.  Ideally, workflows should always be assigned to users based in one of the following categories:

Participant - users are determined based on their inclusion in a security role or a user group. 

Hierarchy - users belong to a specific organizational hierarchy and additional options will determine where in the hierarchy the workflow assignment should land.

There are additional options for assigning a step for completion in the workflow, but they come with their own set of challenges. In both assignment types below, specific, named users, are identified. If these named users are unavailable, system administrators will need to get involved to either reassign or recall the workflow. Additionally, workflows using these assignment types require more frequent changes to the configuration of the workflow, which can lead to additional issues and stuck workflows.

Workflow user - a user that is currently a user of the workflow, including the workflow originator, work item owner, or workflow owner.

User - a custom defined list of users in the system

There are several options to determine the number of approvers you need for a single workflow element.  Depending on the process, you may wish to have more than one approval, and you have several options. Let's create a scenario to see how the options could impact the workflow process.

Company XYZ has 30 people in the AR department. When posting a customer payment journal, a peer review is required to ensure completeness and prevent fraud.

Single approver - only 1 additional peer would review the journal, allowing for a single approval and a minimal amount of time waiting for workflow completion.

Majority of approvers - the majority of the users, more than 50% would need to approve the workflow to complete it. In the case of Company XYZ, 16 users would have to approve the workflow for it to complete.

Percentage of approvers - a custom percentage of users must approve. In the case of Company XYZ, 51% may be too high, and managerment determines only 3 peer reviews are needed. Using simple math we can determine that 10% of the users would need to approve to complete the workflow.  

All approvers - All users in the workflow need to approve before the workflow is completed. It just so happens that 5 members of the AR department are out on vacation this week, delaying the completion of the workflow until all users can approve or a System Admin is involved and can reassign the workflow to management (with proper permission from management of course).

Completion policies can vary from company to company, but potential bottlenecks should be considered when designing and implementing the decision to minimize the need for intervention to complete the workflow process and reduce approval times.

System administration > Workflow > Workflow parameters

Workflow parameters reveal an entity wide decision - should the submitter be prevented from approving their own submission?  This may seem like a silly concept, but when multiple approvals are allowed, this option makes sense to configure to allow the submitter to approve. But there are more cases where, especially in the presence of single approvals, that the submitter should not be able to approve their own submission. If allowed to approve their own submissions and all workflows were single approval, what would be the overall point of workflows?  From an audit and risk perspective, the approver should not be allowed to approve their own submission.

There is a recurring batch job (Workflow message processing) that controls how often workflow messages are processed and updates the approval status from user interaction to the workflow to complete all necessary steps. Intervals of recurrence can be defined but should be frequent enough to prevent too many workflow approval steps requiring processing to build up. I have typically seen this value set to 1 or 2 minutes for recurrence.

 Additional configuration identifying Number of workflow items per batch identifies how many items are processed in a single cycle of the batch. The system default of 0 means the batch job will process 20 items each batch. Microsoft warns and suggests caution in adjusting this number too high, because numbers above 40 can cause SQL deadlocks.