Important note regarding AppleScript actions in Automator workflows.
Hopefully this helps others who are looking for a fix.
Assistive Access
If your script uses things like tell application "System Events"
to get UI data from app windows or send virtual keystrokes, etc, then it'll require "assistive access".
This may be called different things in different versions of Mac OS, but can generally be found in System Preferences > Security & Privacy > Privacy > Accessibility, under "Allow the apps below to control your computer".
Enabling assistive access for the Automator and Script Editor applications will allow your workflows and scripts to run from those tools, but not when saved as standalone apps. In theory, enabling access for any app should also let it talk to System Events.
Problem with AppleScripts run from Automator Actions
But as many have discovered, Automator often has issues creating apps that can be granted assistive access, when such apps contain AppleScript code. Not to mention the fact that services cannot be granted such permissions at all, since they aren't apps.
Workaround
However, you can build standalone AppleScript apps from the Script Editor application instead, and grant them assistive access without issue.
You can then run such apps as part of an Automator or shell workflow, like this:
AppleScript action in Automator
do shell script "osascript -e 'tell application \"My Granted App Name\" to activate'"
Shell Script
(can also be from an Automator action)
osascript -e 'tell application "My Granted App Name" to activate'
This also works for creating services in Automator. Just have your service run the permission-granted app, rather than trying to add permission-requiring code to the service itself.
Note that the tell app
call doesn't require the ".app" extension, or even a path. If you have many apps with the same name, there should be a way to get the app by its bundle identifier, etc.
Other IDEs
I'm not sure if this is a problem specific to Automator, since I haven't tried calling fancy AppleScripts from apps built with tools other than that and Script Editor. Either way, the above should work for other IDEs/compilers/etc. as well.
Re-Building your App
In most cases, editing and re-building a granted app requires it be re-granted access. So it helps to test everything well in Automator/Script Editor before you build the standalone app, to save you the trouble. If your script is called by a larger project you routinely recompile, it's best to turn that script into its own app to grant it access once, and run the app from your larger project. At least until the larger project is finalized.
For apps used by multiple scripts, you could keep them in a consistent spot like a custom /Applications/Tools/Scripts folder. However, remember that any third-party code can launch apps and thus activate your potentially sensitive scripts. It's important to consider security implications when creating code that using assistive access.
When Re-Granting Doesn't Work
There are times when re-granting a rebuilt app doesn't "take". In such cases, renaming the app and re-adding it via System Preferences usually solves this. You should be able to re-name the app back to its original at a later time. This is a bug with how Assistive Access caches its list of apps, and the filename and/or path are involved somehow. If anyone knows how to clear this cache, please add a comment; it would be very helpful.
Depending on how your script is configured, by default, any Service requires to have an item selected / highlighted (in your case, an email) as they are context sensitive.
You can disable this behaviour by changing the drop down field "Service receives" and selecting "no input". This obviously only applies if your script fetches input itself or doesn't need it.
Unfortunately there do seem to be weird issues when services have spaces and/or numbers in their name.
As stated by @gerlos, renaming them should solve the problem, but a reboot might be required (Which was the case for me).
As an extra;
If you're now finding that you don't like the name of the new service, you can change it!
Just right click the .workflow file and select 'show package contents'.
Inside you'll find a configurable info.plist file.
Open it up with your favourite text or plist editor (Or just plain old TextEdit) and look for the xml key 'NSMenuItem', it should contain a key entry 'default' associated with a string, the string in question is the service's display name.
More information on everything that's configurable (e.g. a service description) can be found in the apple documentation here: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/SysServices/Articles/properties.html
Tested on OS X High Sierra
Best Answer
I suspect you may be getting this error because you are trashing folders and files in the same action. In other words, if automator tossed out a folder containing a '.mov' file, it will toss out the '.mov' file as well; then (later) when automator tries to toss that '.mov' file, it cannot find it, because it's already in the trash.
First solution to try: move the
kind is folder
option to the bottom of the list, in the hopes it sorts folders last.If that doesn't work, then you may need to complexify your workflow with a variable, like so: