# Completion handlers and workflow wrappers ## Completion handlers *Completion handlers* are workflows that execute after another workflow has been completed. They provide a mechanism to extend or modify existing workflows without altering their core structure. These workflows have a [context variable ](https://docs.rewst.help/documentation/automations/workflows/data-input-and-output-input-variables-and-context-variables)that can be used to reference previous contexts from the workflow that was completed. Configure completion handlers to either trigger another workflow after the existing one finishes, or execute the current workflow when another workflow is completed. {% hint style="info" %} You might hear some of our support staff or customers who present on our Open Mics refer to completion handlers as *workflow listeners*. Listener is a more coding-focused term that they're already familiar with. A completion handler and workflow listener are the same thing. {% endhint %} ### Example workflow use cases for completion handlers Let's look at a few use cases for using completion handlers: * Taking additional steps after the onboarding workflow is complete * Add additional functionality to an existing synced workflow without having to unsync it from the template. * Alerting for failed workflow executions, like kicking off the completion handler based on a failed status ### Configure a completion handler in a workflow 1. Navigate to **Automations > Workflows**. 2. Locate the existing workflow that you want to address. Click

**Workflow Completion Handlers**. 3. Note the two options in the **Completion Handlers** section. You'll need to choose which one you want to use: 1. Run this workflow when... 1. This will run the workflow when another workflow completes 2. When this workflow completes... 1. This will result in something being done when the workflow completes 4. Define your trigger conditions. This step will differ depending on which of the two options you chose in step 3. 1. For When this workflow completes... 1. Click

to choose the workflow to trigger. 2. Under **Trigger On Statuses**, specify the conditions for the trigger, such as **succeeded,** **failed**, **timed out**, or **canceled**. You can select multiple statuses from the drop-down list. 3. Select your relevant integration or integrations from the drop-down selector. 4. Open each selected integration's accordion menu to choose your **Configuration Selection Mode** for that integration. 5. Make sure **Enabled** is toggled to on. 6. Click **Submit** to save your settings.

An example **Add Completion Handler** dialog for the **When this workflow completes...** option

An example **Add Completion Handler** dialog for the **Run this workflow when...** option

### Access the context of the previous workflow Contexts from the previously run workflow can be accessed with the `COMPLETED_WORKFLOW` variable. You can access most info via the context including ORG and CTX such as: 1. `{{ COMPLETED_WORKFLOW.ORG.VARIABLES.cw_manage_company_id }}` 2. `{{ COMPLETED_WORKFLOW.CTX.user.username }}` {% hint style="danger" %} Completion handlers will always run in the context of the parent organization. If you are taking actions on a suborganization in the workflow, then you must utilize the run-as-organization functionality and overrides set at the completion handler level. The organization ID that was used in the previous workflow context can be referenced with the following Jinja: `{{ COMPLETED_WORKFLOW.ORG.ATTRIBUTES.id }}` {% endhint %} ### Test completion handlers Completion data is hard to fake for testing because it's represented as `COMPLETED_WORKFLOW.` instead of `CTX.COMPLETED_WORKFLOW.` Rather than running an entire workflow multiple times to test just this one element, create a [noop action](https://docs.rewst.help/documentation/workflows/actions-in-rewst/core-actions#no-operation-noop) that sets the test data, and use it to trigger your completion handler. In the noop, set all of the variables that will be used in your completion handler in the On Success transition as data aliases. It’s important that the names of the data aliases you create in the On Success transition of the noop match both: * the names of the variables that will be used in your completion handler * the names of the variables that will be used in the live parent workflow that your completion handler is triggered by Add static values that represent a good test case for ensuring that your completion handler functions the way you expect. #### Example In the example below, we’ve created a workflow with a single noop. In the **On Success** transition, we’ve added several data aliases that represent user data that could be used to test a completion handler, which could be used after a user is onboarded or offboarded.

Screenshot of the Rewst workflow editor showing a single step labeled core_noop. The transition panel on the right displays options to edit the transition, including setting a custom label, moving the step left or right, and selecting a condition (On Success, On Error, Always, or Expression). Below that, a section titled "Data Aliases" shows several variables being mapped: first_name to "Listener", last_name to "Testing", email to "test@rewst.io", license to "Microsoft Business", and password to "RadicalMongoose123!". Each alias has controls for reordering and deleting. A "Sub-Workflow" node is partially visible at the bottom. — The noop action, its On Success transition, and the corresponding data aliases

Once you’ve created the noop and added the correct data, attach this workflow to your workflow completion handler as another parent workflow that will trigger the completion handler. This will enable testing.

Screenshot of a Rewst workflow editor showing a step titled core_noop with an "On Success" transition. On the right, the "Edit Transition" panel is open, allowing users to add a custom label, move the step left or right, and set a condition (Success, Error, Always, or Expression). Several data aliases are configured, mapping variables like first_name, last_name, email, license, and password to static values. At the top of the screen, multiple icons are visible, and a red arrow highlights the "Show Workflow Variables" icon, which resembles two stacked squares with a connected line between them. The workflow is titled "Listener Test." — The location of the button

Screenshot of the "Listener Test" workflow configuration in Rewst. The tab "When this workflow completes..." is selected, showing a section titled "Workflows listening for the completion of this Listener Test workflow." No workflows are currently listed. Columns for trigger conditions include: On Succeeded, On Failed, On Timeout, and On Canceled. An orange arrow points to a teal plus (+) icon in the Actions column, indicating where users can add a new workflow listener. The bottom portion of the screen shows the workflow canvas and the "Edit Transition" panel with controls for labeling and positioning transitions. — Click + to attach the workflow to the workflow completion handler

Click **Test** to run the workflow. This will feed the variables that you’ve set with your completion handler and trigger it to run, allowing you to confirm if the variables are used as expected. If you need to run your test workflow for organizations other than your parent MSP organization, add a trigger to the workflow which will allow you to select which organization the test workflow runs for. Alternatively, re-run from the workflow result page of the workflow that kicks off the completion handler. This would still run the workflow in total, but would be a simpler way to achieve it with fewer clicks. ## Workflow wrappers *Workflow wrapper* is an informal term used colloquially by Rewst support to describe a situation where a primary workflow is used in a separate workflow as a [subworkflow](https://docs.rewst.help/documentation/automations/workflows/..#subworkflows). Whereas a completion handler only runs when a workflow completes, a workflow wrapper can run before or after completion. *Workflow wrapper* is an informal term to describe a parent workflow that "wraps around" a subworkflow. You apply this strategy when you want certain tasks to run before or after the tasks within a subworkflow, and want to visualize the process on one workflow canvas. For example, you might create a workflow wrapper to handle custom input from a Rewst form, prior to a Crate running. The visual below shows this strategy, running a few tasks before the Microsoft User Onboarding subworkflow.