Applications → Using Actions → Considerations for Using Actions
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
- Actions can be defined for all transition types, but only
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
- When a transition action invokes a
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
- Do not use "transition," "continue executing
(asynchronous) orchestration workflow," or "trigger" action types on an
incoming transition to a decision.
SBM Application Engine
executes Web service functions,
scripts, transition attribute
scripts, transition actions and state actions, and events, in the
- Web service function for the pre-transition context
- Script for the pre-transition context
- Transition attribute scripts for the
- Transition executed by users
- Script for the post-transition context
- Transition attribute scripts for the
- Web service function for the post-transition context
- Script for the post-state context
- Web service function for the post-state context
- Script for the pre-state context
- Web service function for the pre-state context
- Transition completed and recorded in the database
- Transition actions
- Events are emitted
- Subtasks and posted items are submitted
- 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).
Copyright © 2007–2018 Serena Software, Inc., a Micro Focus company. All rights reserved.