I build automator workflows like this all the time. You only need two actions, and they're both Files & Folders actions.

1) Get Specified Servers. This will let you build a list of shares to connect to. If you can map it from Finder -> Go -> Connect to server, you can use this.

2) Connect to Servers. This will connect to any servers passed to it (either from get specified servers or from ask for servers).

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.