These posts were published 4 years ago (yes, have over 4 years experience with SA :-)). If you are on CP2017, the screenshots may be a little bit different because of the change to the Advanced Actions dialog box (see AA Dialog in 2017). However the work flow and terminology for Shared actions is still the same.

Following on those tutorials I explained a bunch of use cases where shared actions were used. Examples are the way to explore new features, and you’ll find a list with links here:

This blog post has a unique shared action that you’ll be ablefor several toggle button in all your projects. The post was written  for Captivate 8. If you are using Fluid Boxes work flow (responsive projects) in CP2017, you can have the toggle buttons in a fluid box on master slides, not timed for the rest of the project (unless  in a static fluid box).

The advantage of shared actions when setting up a menu or dashboard

When using object actions for Drag&Drop slides, shared actions can be an excellent choice over duplicate advanced actions

Using shared actions to create a custom controlled hotspot question which has lot of advantages over the default type of Hotspot question.

This is an older version of the Example movie for which I posted a link above. It did already use Shared actions.

Games often need repetitive actions and that means that shared actons are the way to go.

Another version of a dashboard created with shared actions, to celebrate the arrival of CP9.

Strange myths exist about Shared actions. Lot of users believe they are only useful  between projects, not in the same  project. Personally, with the exception of the external library mentioned at the beginning, I always give priority on shared actions within one project over advanced actions if appropriate. If an action is used at least twice in a project, and it is possible to use a shared action, I will not use duplicate advanced actions.

Half-myth is that you cannot edit a shared action. That is partially true. You cannot edit a shared action which is already assigned to events and have it changed automatically. However you can use the original shared action as template to create a new shared action. You will have to assign it to all events after completing the new shared action. At that moment you will appreciate the fact that the shared action appears in the Library and has a Usage button  –  like any other asset. Contrary to advanced actions you can even reuse the same name for a shared action, provided the older action is no longer present in the file. That is one of those annoying things, that you can never reuse a name for an advanced action, even if it has been deleted. Keeping track of Usage of advanced actions is also very cumbersome.

Shared actions cannot replace advanced actions in all circumstances, and they need a different set of mind when preparing the actions. You have to be very careful with the candidate parameters: variables and literals.  I could tell a lot about spectacular results when replacing advanced by shared actions that are set up in an efficient way: courses that couldn’t be published anymore because of the number of variables and advanced actions that now run very smoothly, decrease of file size and loading time when using shared instead of advanced actions. Once lot of Captivate users gave me the title ‘Queen of Advanced Actions’. At this moment I feel more like the defender of Shared Actions, not the first ignored and underestimated stepchild of Captivate.  Too often I hear comments like: ‘I cannot see any advantage in using shared over advanced actions’.  Sorry, but that means you never tried them out. This article proves that I have explored them…. and they are on my top feature list of Adobe Captivate.