Action Best Practices

This page includes the following:

Naming Conventions

When creating a new custom Pack, the following naming convention should be followed:

To create a new Action within this Pack , the following naming convention should be used:

Custom Packs should be stored in the Packs folder, at the same level as the out-of-the-box Packs.

Action Pack Structure

Structurally, a Pack consists of all of the following:

Actions are parameterized input/output variables in prompts within the action workflows. This means that they can be created to be used in any environment and for any deployment that may use this action.

All custom Actions should be created under the same Pack which will hold the specific technology defined.  If another set of actions belongs to a new technology, a new Pack must be created to store these new Actions.

Documentation

Documentation for the custom action must be provided at the time of creation. This must include as much information as possible to better explain how to use the Action.

The documentation provided for the action should include short description to make clear what the Action is meant to be used for.

Shared Objects, Actions and Components

Often several Actions within an Action Pack use the same objects. Similarly, several Component Workflows may use the same Actions.

To speed up development, improve consistency and implement deployment best practices, you can create "shared" objects and composite Actions to be used across different Applications. See: Working with Actions.

These are likely to be:

Tip: Save these objects/Actions in a common folder:

Watch the video to learn how to share the deployment logic between Applications by using a composite Action:

Return Values

After each critical UNIX/Linux command, use the following include statement to retrieve the return code and exit/block accordingly: