Amazon Simple Workflow Service
Developer Guide (API Version 2012-01-25)

Advanced Concepts in Amazon SWF

The e-commerce example in the Basic Concepts in Amazon SWF section represents a simplified workflow scenario. In reality, you are likely to want your workflow to do concurrent tasks (send an order confirmation email while authorizing a credit card), record major events (all items are packed), update the order with changes (add or remove an item), and make other more advanced decisions as part of your workflow execution. This section describes advanced workflow features that you can use to construct robust and sophisticated workflows.


Business needs often require you to have different implementations or variations of the same workflow or activity running simultaneously. For example, you might want to test a new implementation of a workflow while another one is in production. You might also want to run two different implementations with two different feature sets, such as a basic and premium implementation. Versioning enables you to run multiple implementations of workflows and activities concurrently, for any purpose that meets your requirements.

Workflow and activity types have a version associated with them which is specified at registration time. Version is a free-form string and you can choose your own versioning scheme. In order to create a new version of a registered type, you should register it with the same name and a different version. Amazon SWF Task Lists, described earlier, can further help you to implement versioning. Consider a situation in which you have long-running workflow executions of a given type already in progress, and circumstances require that you revise the workflow, such as to add a new feature. You could implement the new feature by creating new versions of activity types and workers, and a new decider. Then you could launch executions of the new workflow version using a different set of task lists. This way, you could have executions of workflows of different versions running simultaneously without affecting each other.


Signals enable you to inject information into a running workflow execution. In some scenarios, you might want to add information to a running workflow execution to let it know that something has changed or to inform it of an external event. Any process can send a signal to an open workflow execution. For example, one workflow execution might signal another.

To use signals, define the signal name and data to be passed to the signal—if any. Then, program the decider to recognize the signal event (WorkflowExecutionSignaled) in the history and process it appropriately. When a process wants to signal a workflow execution, it makes a call to Amazon SWF (using the SignalWorkflowExecution action or, in the case of a decider, using the SignalExternalWorkflowExecution decision) that specifies the identifier for the target workflow execution, the signal name, and the signal data. Amazon SWF then receives the signal, records it in the history of the target workflow execution, and schedules a decision task for it. When the decider receives the decision task, it also receives the signal inside the workflow execution history. The decider can then take appropriate actions based on the signal and its data.

Some applications for signals include the following:

  • Pausing workflow executions from progressing until a signal is received (e.g., waiting for an inventory shipment).

  • Providing information to a workflow execution that might affect the logic of how deciders make decisions. This is useful for workflows affected by external events (e.g., trying to finish the sale of a stock after the market closes).

  • Updating a workflow execution when you anticipate that changes might occur (e.g., changing order quantities after an order is placed and before it ships).

For cases in which a workflow should be canceled—for example, the order itself was canceled by the customer—the RequestCancelWorkflowExecution action should be used rather than sending a signal to the workflow.

Child Workflows

Complicated workflows can be broken into smaller, more manageable, and potentially reusable components by using child workflows. A child workflow is a workflow execution that is initiated by another (parent) workflow execution. To initiate a child workflow, the decider for the parent workflow uses the StartChildWorkflowExecution decision. Input data specified with this decision is made available to the child workflow through its history.

The attributes for the StartChildWorkflowExecution decision also specify the child policy, that is, how Amazon SWF should handle the situation in which the parent workflow execution terminates before the child workflow execution. There are three possible values:

  • TERMINATE: Amazon SWF will terminate the child executions.

  • REQUEST_CANCEL: Amazon SWF will attempt to cancel the child execution by placing a WorkflowExecutionCancelRequested event in the child's workflow execution history.

  • ABANDON: Amazon SWF will take no action; the child executions will continue to run.

After the child workflow execution starts, it runs like a regular execution. When it completes, Amazon SWF records the completion, along with its results, in the parent workflow execution's workflow history. Examples of child workflows include the following:

  • Credit card processing child workflow used by workflows in different websites

  • Email child workflow that verifies the customer email address, checks the opt-out list, sends the email, and verifies that it didn't bounce or fail.

  • Database storage and retrieval child workflow that combines connection, setup, transaction, and verification.

  • Source code compilation child workflow that combines building, packaging, and verification.

In the e-commerce example, you might want to make the Charge Credit Card activity a child workflow. To do this, you could register a new Verify Customer workflow, register the Verify Customer Address and Check Fraud DB activities, and define coordination logic for the tasks. Then, a decider in the Customer Order workflow can initiate a Verify Customer child workflow by scheduling the StartChildWorkflowExecution decision that specifies this workflow type.

The following figure shows a customer order workflow that includes a new Verify Customer child workflow, which checks the customer address, checks the fraud database, and charges the credit card.

               Diagram of child workflow

Multiple workflows could create child workflow executions using the same workflow type. For example, the Verify Customer child workflow could also be used in other parts of an organization. The events for a child workflow are contained in its own workflow history and are not included in the parent's workflow history.

Because child workflows are simply workflow executions that are initiated by a decider, they could also be started as normal stand-alone workflows executions.


At times, you might want to record information in the workflow history of a workflow execution that is specific to your use case. Markers enable you to record information in the workflow execution history that you can use for any custom or scenario-specific purpose.

To use markers, a decider uses the RecordMarker decision, names the marker, attaches desired data to the decision, and notifies Amazon SWF using the RespondDecisionTaskCompleted action. Amazon SWF receives the request, records the marker in the workflow history, and enacts any other decisions in the request. From that point on, deciders can see the marker in the workflow history and use it in any way that you program.

Examples of markers include the following:

  • A counter that counts the number of loops in a recursive workflow.

  • Progress of the workflow execution based on the results of activities.

  • Information summarized from earlier workflow history events.

In the e-commerce example, you might add an activity that checks the inventory every day and increments the count in a marker each time. Then, you could add decision logic that emails the customer or notifies a manager when the count exceeds five, without having to review the entire history.


Amazon SWF enables you to associate tags with workflow executions and later query for workflow executions based on these tags. Tagging enables you to filter the listing of the executions when you use the visibility operations. By carefully selecting the tags you assign to an execution, you can use them to help provide meaningful listings.

For example, suppose you run several fulfillment centers. Proper tagging could enable you to list the processes occurring in a specific fulfillment center. Or, to take another example, if a customer is converting different types of media files, tagging could enable you to show the processing differences used for converting video, audio, and image files.

Amazon SWF supports tagging a workflow execution with up to five tags. Each tag is a free-form string and may be up to 256 characters in length. If you want to use tags, you must assign them when you start a workflow execution. You can't add tags to a workflow execution after it has been started, nor may you edit or remove tags that have been assigned to a workflow execution.