SharePoint Designer workflow in general is best used as a facilitator of actions that make up a business process and it does not work well for automating or enforcing an entire, complex, human process. What I mean is that SharePoint Designer workflow is best used to automate certain actions that occur within a business process like assign a status of something, or email something, or copy something but its not going to replace human decision making and its not going to perform the entire business process for you.
Say, for example, that Company ABC's IT team is supporting 100 employees through email exchanges. When an employee has an issue, they email an IT distribution list then the IT staff responds to the issue. The IT team is finding that they are struggling to keep track of the support requests. They are considering using SharePoint to track support requests.
A solution to this business problem may be to use SharePoint to structure the metadata about support requests and use workflow to automate actions that occur during the process. Create a SharePoint custom list to track support requests with request id, requestor email, status, title, description, solution fields, and then use SharePoint Designer workflow to perform the following:
* Automatically generate request id for new support requests
* Automatically build and send email the requestor when status of items is changed
SharePoint Designer should not be used to implement rigid rules that contain deep branchings for how the support requests are resolved. You do not want to attempt to create a workflow that predicts and solves the support requests that you are tracking within SharePoint. Thining through and resolving support requests is a complex human process and it scales beyond practical limits of SharePoint Designer workflow.
Workflow can certainly improve processes, and it can simplify tasks that a person performs during a business process, such as the example above....just don't expect workflow to do somebody's job for them.