Considerations for Using Actions

Consider the following when you set up actions:

• Actions can be performed on items transitioned manually by users, by other actions, or by mass updates.
• Actions must be defined at the level at which a state or transition was created and cannot be overridden for a sub-workflow or project.
• All actions must conform to the workflow. In other words, you cannot use an action to execute a transition that is not already defined in the workflow.
• Actions can be defined for all transition types, but only Regular, Copy, Post, and Subtask transitions can be executed as a result of an action.
• To ensure that actions execute properly, make sure there are no required fields for the transition that will execute as a result of an action. If necessary, provide default values for data in fields required for any transition that contains an action.
• You can define multiple actions for a transition. To the extent possible, actions are executed in the order in which they are listed on the Actions tab of the Property Editor for the selected transition or state. Use Move up and Move down to reorder actions as needed.
• If actions are used to execute multiple transitions on an item, Item Type restrictions may prevent subsequent transitions from executing.
• If you have multiple transition actions, the first one that evaluates as true prevents the evaluation of further actions.
• If you have an orchestration action, it must be last (it cannot be ordered with the other actions), and the orchestration workflow will not be invoked if a previous transition action was executed. If the orchestration workflow must always run, the setup must be designed to account for that (for example, have the orchestration action on the transition, and find a way to move the transition actions to the next state).
• When there are multiple asynchronous orchestration actions on the same transition, only one event of each event type is raised. Events start orchestration workflows that will run simultaneously depending on available resources, so the ordering of event actions on the Actions tab has no effect on the execution order of the orchestration workflows.
  • If you specify multiple local event actions, the orchestration workflows that are specified will all be triggered by that one event.
  • If you specify multiple external event actions, then only one event of each type will be raised, and the data mapping specified by the first one in the list that is of that type will be used.
  Note: An event type is a distinct combination of ProductName, Version, ProductInstance, EventType, and ObjectType. This combination defines the matching criteria for an event, whether it is defined as a local event or an external event.
• When a transition action invokes a Post or Subtask transition and you do not specify a post-item project in SBM Application Administrator, if only one valid project is available, the submit defaults to the valid project. If there are multiple projects available, the submit does not occur and an error is generated.
• When a transition action affects parent or child items, the affected item must be in a state that is valid for that transition. For example, suppose a "Referenced items in relational field" transition action defines that a transition from State 2 to State 3 be executed on the specified parent item. If the parent item is not in State 2 when the transition with the action is executed, it will remain in its current state instead of moving to State 3.
• If an action fails, an error is recorded in the Event Viewer and displayed to users in the Item Details frame for the item that initiated the action.
• Do not use "transition," "continue executing (asynchronous) orchestration workflow," or "trigger" action types on an incoming transition to a decision.

• The SBM Application Engine executes Web service functions, scripts, transition attribute scripts, transition actions and state actions, and events, in the following order:

  1. Web service function for the pre-transition context
  2. Script for the pre-transition context
  3. Transition attribute scripts for the pre-transition context
  4. Transition executed by users
  5. Script for the post-transition context
  6. Transition attribute scripts for the post-transition context
  7. Web service function for the post-transition context
  8. Script for the post-state context
  9. Web service function for the post-state context
  10. Script for the pre-state context
  11. Web service function for the pre-state context
  12. Transition completed and recorded in the database
  13. Transition actions
  14. Events are emitted
  15. Subtasks and posted items are submitted
  16. State actions are performed

  Required field attributes are validated after the transition is executed by a user (step 4) and before the post-transition context (step 5).