Tips for Troubleshooting Automator Workflows
Automator's great for streamlining time consuming and repetitive tasks on your Mac. It's easy. Just launch it, find a few actions, and string them together to form a workflow. Then, run your workflow anytime you want to perform that series of tasks again.
What happens if your workflow doesn't run as you expect, though? Finding and solving problems in Automator is often easier said than done. Suddenly, the simple tool that's supposed to make your life easier has become a real pain in the neck. This week's post covers some things you can do to troubleshoot a finicky Automator workflow, track down the problem, and hopefully solve it, so you can get back to work.
1. Run Saved Workflows in Automator
Automator workflows are saved and run in a variety of ways - as apps, iCal alarms, print plugins, and more. When a saved workflow encounters a problem, however, it may be next to impossible to figure out what went wrong. This is because saved workflows don't really include any diagnostic tools. In some cases, the workflow may even fail silently, without alerting you that something is wrong. Your only indication of a problem may be a lack of the end result you were expecting. Not very helpful, especially in a longer multi-action workflow. When you encounter a problem with a saved workflow, your best bet is to open up the workflow in Automator, and try running it there. By doing so, you'll gain access to some of the techniques described below.
2. Fake Workflow Input
When you run a workflow app or plugin within Automator, you may see an alert indicating that the workflow will not receive input.
An Automator Input Alert for a Text Service Workflow
This is because, often, saved Automator workflows expect input for processing. For example, a workflow app may expect dropped files or folders as input, a service workflow may expect text as input, or a print plugin may expect PDF files from the print system. In any case, just dismiss the alert and add an action to the beginning of the workflow to retrieve the required type of input. If your workflow processes files, for example, add a Get Specified Finder Items action. If your workflow processes text, add a Get Specified Text action. Whatever you add, just be sure to remove it once you're finished troubleshooting.
Get Specified Text at the Beginning of a Text Service Workflow
3. Check Action Results
Automator works by passing information to actions for processing. Most actions perform a very specific function. As such, they accept specific types of information as input. And, they produce different types of output. The New TextEdit Document action, for example, wants text as input. It then adds this text to a new TextEdit document, and passes the document as output for further processing.
Often, when a workflow fails or produces an undesired result, it's because actions aren't receiving or producing the expected types of information. To diagnose this problem, click the Results button beneath each action in your workflow. Then, when you run the workflow, you can see exactly what information is being passed from action to action.
Suppose, for example, I have a workflow that should take the contents of a text file and add it to a new TextEdit document. I may try creating my workflow with the following actions:
Get Specified Finder Items - Configured to get a text file
Filter Paragraphs - Configured to look for non-empty paragraphs
New TextEdit Document
All the actions appear to link up properly, and the workflow may even run without an error. But, the result is not what I want. Rather than the content of the text file being added to the new TextEdit document, the path of the document is added.
A Misbehaving Text Workflow
An Undesired Workflow Result
By displaying the result area of each action in the workflow, I can see that a file path was passed to the Filter Paragraphs action as input. I can also see that the same file path was output by the action, rather than the paragraphs I was expecting. This tells me that there's something wrong with the Filter Paragraphs action.
Action Results Indicate Potential Problems
Checking the action's description area provides additional clues. It tells me the action expects text as input, not files.
Action Descriptions Specify Input and Output Types
So, in this case, the fix is to insert an action that outputs text, rather than files, before the Filter Paragraphs action.
NOTE: Surprisingly, Automator doesn't include an action for reading text from a file. There are third-party actions available that can do this. Or, as a workaround, you can try using the Combine Text Files action, which receives one or more files as input and outputs their text content.
4. Check Automator's Log
Checking the results of an action doesn't always tell you what went wrong. You may glean a little more information by consulting Automator's log area. Press Command+Option+L or choose View > Log to display it. When you run a workflow, the log area tells you which actions ran, and often indicates problems that were encountered along the way, such as an action that wasn't supplied with the appropriate type of input.
Automator's Log Area Indicates Successes and Failures
Sometimes, the log tells you that information was converted from one type to another. This is because, in some cases, Automator tries to make incompatible actions work together. This doesn't always work, however, and can result in an error. So, be on the lookout for failed conversions.
5. Step Through Workflows
Running a workflow and checking action results is great, but it's even more useful to check the results of each step of your workflow as it happens. You can do this by stepping through the workflow step by step. Click the Step button in the workflow's toolbar or select Workflow > Step from the menu bar.
Automator's Step Button
The above techniques may not resolve every problem you encounter with Automator, but they will certainly help you to more easily identify solutions for some. Happy Scripting!
