Cisco Cloud Control Workflows

 
Updated July 8, 2026
PDF
Is this helpful? Feedback

Workflows

Automation workflows allow you to automate responses and eliminate repetitive tasks, using activities, logic, and even other workflows to communicate with other systems and resources. From the Workflows page, you can access your individual workflows and atomic actions, and view the most recently run workflows and your favorite workflows. The All Workflows tab allows you to access, create, and import workflows.

Automation rules is an example to execute a workflow. Other examples include using API requests and manually selecting the Run button.

Create a workflow

To create a workflow, use the Workflow Editor to drag objects such as activities, logic components, and other workflows from the Activities panel to the canvas and then configure the properties for each of the objects.

Before you begin, configure any Targets that your workflow will communicate with.

  1. In the top navigation bar, select app-launcher.jpg.

  2. Under Platform, select Workflows.

  3. Select Create.

  4. Choose a type according to the intent of this workflow, and select Continue.

  5. In the Properties panel of the Workflow Editor, define the workflow properties.

  6. From the Activities panel, drag and drop activities, logic, or other workflows onto the canvas.

  7. Select each object in the workflow and define its properties in the Properties panel. The exact properties necessary will vary among workflow objects.
    For example, you can select the Variable Reference icon to use the variable browser to explore all of the variables available while building a workflow.
    The variable browser is hierarchical, and variables are only available within the scope in which they are defined.

  8. When you have completed constructing the workflow, select Validate to verify that the workflow is valid.
    If you have invalid activities, they will be displayed with an orange bar, and a warning will be displayed in the upper right corner of the Properties panel.
    Resolve any issues and validate the workflow again.
    After the workflow has been created and successfully validated:

    • To edit the workflow after the run completes, select Modify to open the workflow for editing.

    • To execute the workflow, select Run. You can then view the status of the workflow from the Runs page.

    • To export the workflow to your Git repository, select Share > Commit To Git.

    • To request that the workflow be published to Exchange, select Share > Submit to Exchange.

Workflows and atomics

The Workflows and Atomics tabs display a card or list row for each workflow or atomic action in your environment.

By default, the All Workflows and Atomics tabs are displayed in a tiled Card View. If you have many workflows or atomics, you can change the view to a more compact List View.

Categories

Categories are tags for grouping workflows within the Workflow Editor. Automation ships with pre-defined categories and allows you to create your own business-specific categories.

Git repositories

Use the Git Repositories page to add, modify, or delete the Git repositories that house your workflows and atomic actions. Select a repository from the list to view and modify its properties.

Custom tab

You can create and display up to five tabs with user-defined categories on the Workflows page. Select the downward arrow icon and choose up to five tabs by selecting the pin icon. The default tabs are Workflows, Atomics, Recently Run, and Favorites.

  • Recently Run are workflows that have run recently.

  • Favorites are workflows that you select. You can use favorites to mark workflows that you want to find more easily. To set a workflow as a favorite, select the gray star in the lower left corner of the workflow card or after the workflow name in the list row.

To add a custom tab, create and save a custom filter.

Custom filter

You can Search for workflows by entering names or keywords, or filter by Saved Filters, Ready State, or Category.

You can save the custom filter you’ve created and add it as a custom tab to the Workflows page:

  1. After you configure the filter, select Add to Saved Filters.

  2. Enter a meaningful filter name and select Save.

  3. Select the downward arrow icon next to Workflows and select the filter to add a tab for it.

  4. Select any pinned filter to remove its tab.

View summary of Workflow in Drawer

When you select a workflow, the Workflow drawer opens on the right, which displays a summary of the workflow to help you quickly understand it at a high level.

The summary includes information such as description, categories, response actions, variables, triggers, and targets.

To view more information about the workflow, select View workflow to open the Workflow Editor.

To close the drawer, select the X at the top-right corner or anywhere outside the drawer.

With the drawer open, you can select other workflows to view their summaries, enabling you to look through multiple workflows quickly.

To bypass the Workflow drawer and open the Workflow Editor directly, either select the open in window icon next to the name or hold down the command (Mac) or Ctrl (Windows) key when you select a workflow.

Workflow and atomic menu actions

In each workflow or atomic card or list item, you can perform actions from the menu.

Some of the menu options (Delete or Uninstall) depend on whether the workflow was installed from the Exchange. For workflows installed from the Exchange, the Uninstall option is displayed; for all other workflows, the Delete option is displayed.

If you’re using the card view, hover the mouse on the workflow card and select the ellipsis (…) to see the menu options:

If you’re using the list view, hover the mouse on the list item and select the ellipsis (…) in the Actions column to see the menu options:

  • Used By - See all other workflows that use or have a dependency on this workflow or atomic action.

  • Run - Perform a single execution of the workflow or atomic action.

  • Duplicate - Use this option to make a copy of the workflow so that you can modify it without changing the original workflow.

  • Export - Export the workflow as a JSON. You can copy the JSON text or save the output as a file.

  • View Runs - Takes you to the Runs & System Monitor page where you can view a history of the workflows runs.

  • Delete - This option is displayed for custom workflows or any other workflows not installed from the Exchange. Use this option to delete the workflow or atomic action from your environment.

  • Uninstall - This option is displayed if the workflow was installed from the Exchange. Use this option to uninstall the workflow and sub-workflows from your environment.

You can easily identify the workflows that were installed from the Exchange:

  • In the card view, the (Exchange) icon is displayed in the lower right corner of the workflow card.

  • In the list view, Exchange is displayed in the Categories column.

Important notes and limits

  • A workflow must be in a valid state to be executed manually or triggered by an event. For example:

    • If you change a workflow but do not validate it, the next time the workflow is scheduled to run, it may fail to execute.

    • If you have a workflow configured with an Email rule and you are working on the workflow when an email arrives, the workflow may fail to execute if it is not in a valid state.

    • Before you can successfully run a response workflow from the pivot menu, open the workflow in the Workflow Editor to validate the workflow. Once the workflow is validated, you can select it to run it from the pivot menu. When you select a workflow to execute, you’ll see a small success message at the bottom right of the page. Note that this success message only indicates that the workflow was started successfully; it does not mean that the workflow completed successfully. To view the workflow’s status and result, go to the Runs page.

If you want to import an updated version of a workflow that you already have, any changes you have made are overwritten. To avoid overwriting your changes, you can import a workflow as a copy.

You can mark a workflow as a favorite by selecting the star icon in its card or list row.

To preserve system resources and ensure the integrity and performance of the platform, there are some limits put in place around workflows:

  • Design limits:

    • Maximum number of workflows: 500

    • Maximum number of atomics: 500

    • Maximum number of workflow variables: 100

    • Maximum number of custom variable types (array, object, and table) allowed is 200 total per organization.

    • Maximum size of a Large String variable is 10MB.

    • Maximum size of a String variable is 1MB.

    • Maximum size of a Table variable is 1MB.

    • Maximum number of workflow actions (all kinds): 200

    • Maximum number of sub-workflow activities per workflow: 30

    • Maximum number of atomic activities per workflow: 30

    • Maximum number of For Each logic activities per workflow: 20

    • Maximum number of Parallel Block logic activities per workflow: 10

    • Maximum number of While Loop logic activities per workflow: 20

    • Maximum depth of nested loop blocks per workflow: 3

    • Maximum number of workflows that you can have published in Exchange: 100

    • If a limit is reached, you receive a banner, toast, or in-page footer notifying you of the specifics.

  • Run time limits:

    • Maximum total loop runs per workflow: 50,000 iterations (includes loop counts from all logic actions in a workflow)

    • Maximum number of iterations a For Each or While Loop can run: 500

    • Maximum workflow run time: 30 minutes

    • If a limit is reached, the workflow fails with the run status of workflow_timeout.

  • API run limits:

    • Start API, rate limit is 20 per minute

    • Webhook API, rate limit is 20 per minute

    • Instances API, rate limit is 50 per minute

    • All APIs other than Start/Webhook/Instances, rate limit is 8,000 per hour

  • Other Limits:

    • Calendar: 100

    • Data Types: 200

    • Remote Targets: 20

    • Runtime Users: 300

    • Account Keys: 300 per organization

Exchange overview

The Exchange page is used to find, view, install, and uninstall pre-written workflows that have been released or approved by Cisco engineers and content providers.

On the Explore tab, you can locate useful workflows, learn more about them, and streamline the workflow installation process using the built-in wizard.

  • Featured - Includes newly published workflows or workflow packages that address notable user issues that you may want to investigate.

  • Popular - Includes the most popular installed workflows across all Automation user tenants.

  • All Workflows - Includes all the workflows that are currently available from Exchange.

On the Installed tab, the table lists just the workflows in your tenant that you’ve installed from Exchange, if any. The searchable and sortable table shows you the author, install date, and state of the workflow (*Installed, Install Failed, Update Available, Update Failed). The Actions include view details of this workflow, view this workflow on the Workflows page, and Uninstall this workflow.

On the Submissions tab, the table lists all the workflows in your tenant that have been submitted for publishing to Exchange, if any. The table, both searchable and sortable, shows the workflow category/integration, author, authorship type, when it was submitted, and current status.

For information on how to submit and manage requests to publish a validated workflow to Exchange, refer to Publish to Exchange.

Authorship types

Next to the name of the workflow is a tag identifying who created the workflow.

  • Cisco Managed - Authored by Cisco and supported by Cisco TAC.

  • Cisco Verified - Authored by a Cisco Networking Technology Partner and supported by that partner.

  • Community - Authored by the community, passed a basic quality check, and supported by the Cisco Community on a best-effort basis.

Publish to Exchange

This feature enables you to share validated workflows in your tenant with other users of Exchange. With the Administrator role and as a content author, you can create or edit a workflow and, after you validate it, request that it be published to Exchange. The Exchange manager, or content moderator, will then review the submitted workflow and either approve or reject the request. Approving the request publishes the workflow to Exchange and makes it available to install and use by everyone. Thereafter, you can also submit updated versions of published workflows or unpublish your workflows from Exchange. The maximum number of workflows that you can have published in Exchange at a given time is 100.

Submit a publish request

When publishing to Exchange, adhere to the licensing agreement and Workflow Best Practices. Otherwise, your request may be rejected.

After you submit it, you may be contacted by the content moderator with questions or feedback about your request.

  1. Open the workflow in the Workflow Editor, and Validate the workflow.

  2. In the header, select More Actions > Share > Submit to Exchange.

  3. A request form is created; fill in the metadata as follows in Steps 4 to 12.

  4. Enter a meaningful Display Name for the request; use unique names to avoid confusion.

  5. For Authorship Type, all workflows are submitted as Community, by default. The Authorship Type can be changed by the moderator later, if applicable.

  6. Enter the name of the Author of the workflow.

  7. Select the appropriate integration(s) from the Integration drop-down list. And from those, choose a primary integration to display its logo on the workflow card.

  8. If the workflow was created with or assigned a specific intent, its intent will be displayed here.

  9. Enter your Contact & Support Information (email address or URL) which will be visible to other users for questions or feedback about your submission.

  10. Enter a Short Description of the workflow.

  11. Enter any Installation instructions (this long description can also be entered in Markdown language and previewed).

  12. Select ADD to include any links (Title and URL) to references and other helpful information.

  13. Select Save. Your request is added to the Submissions table with its Status as Saved, but not yet submitted.

  14. Before you submit your request, you may Edit or Delete it. When your request is ready, select Submit for Review.

  15. Enter a release note describing the change(s) in this version. Text will be viewable but not editable after submission.

  16. Select Continue and Submit.

Its Status will show Submitted in the Submissions table.

If you want to add comments for the content moderator to view during the review, select your submission and select Comments to open the audit trail. Enter your comment and select Save. Afterwards, comments cannot be edited or removed.

The audit trail shows the submitted workflow’s history, including time stamps, versions, and status changes, such as the initials of who submitted the workflow and when it was approved for publishing.

If your request is reviewed and approved by the content moderator:

  • You receive a pop-up by the notification bell in the header saying your workflow has been approved.

  • Its Status will show Published in the Submissions table.

  • Go to Exchange and you’ll find that your workflow is now available to be installed by any user of Exchange.

If your request is reviewed and rejected by the content moderator:

  • You receive a pop-up by the notification bell in the header saying your workflow has been rejected.

  • Its Status will show Rejected in the Submissions table.

  • To try again, update your workflow accordingly before submitting another request to publish it.

Manage publish requests

The content moderator will either approve or reject a request to publish to Exchange. During their review of the request, if the moderator has any questions or feedback about the workflow, they will try to contact the author or requestor by using the email address entered in the Contact & Support Information field.

  1. On the Exchange page, select the Submissions tab.

  2. The table lists all the requests that have been submitted for publishing to Exchange. The table, both searchable and sortable, displays the workflow category/integration, author, authorship type, when it was submitted, and current status.

The Status column indicates whether the request has been:

  • Saved - And not yet submitted. Under Actions, select to edit, delete, or view the details of the request with the option to submit it for review.

  • Submitted - Awaiting review by the content moderator for approval or rejection. Under Actions, select to view the details of the request.

  • Published - Request approved and workflow published. Under Actions, select to view the details of the request or unpublish the workflow.

  • Rejected - Request rejected and workflow not published. Under Actions, select to view the details of the request.

  • Unpublished - Workflow no longer published to Exchange. Under Actions, select to view the details of the request or delete it.

    1. Select a submission to view its details, and perform a further action such as:

  • Delete, edit, or submit a saved request.

  • View the comments you shared with the content moderator, view their replies, and add more comments as needed.

  • Unpublish a published workflow.

  • Delete an unpublished workflow.

Publish an updated version

If you change a workflow that was previously published to Exchange, you can publish the updated version to Exchange.

  1. Open the updated workflow in the Workflow Editor, and Validate the workflow.

  2. In the header, select More Actions > Share > Submit Update to Exchange.

  3. The metadata is copied over from the prior version, and you’re able to edit it as needed.

  4. Select Save. Your request is added to the Submissions table with its Status as Saved, but not yet submitted.

  5. Before you submit your request, you may Edit or Delete it. When your request is ready, select Submit for Review.

  6. Enter a release note describing the change(s) in this version. Text will be viewable but not editable after submission.

  7. Select Continue and Submit. Its Status will show as Submitted in the Submissions table.

If you want to add comments for the content moderator to view during the review, select your submission and select Comments to open the audit trail. Enter your comment and select Save. Afterwards, comments cannot be edited or removed.

The audit trail shows the submitted workflow’s history, including time stamps, versions, and status changes, such as the initials of who submitted the workflow and when it was approved for publishing.

If your request is reviewed and approved by the content moderator:

  • You receive a pop-up by the notification bell in the header saying your workflow has been approved.

  • Its Status will show Published in the Submissions table.

  • Go to Exchange and you’ll find that your workflow is now available to be installed by any user of Exchange.

  • Open the workflow to learn more by viewing its details, and you’ll see next to its name a version number that increases every time a newer version of the workflow is published to Exchange.

  • When an updated workflow is published to Exchange, Automation users already using that workflow have the option of updating to the newer version. For more information, see the Exchange - Update an Installed Workflow Help topic.

If your request is reviewed and rejected by the content moderator:

  • You receive a pop-up by the notification bell in the header saying your workflow has been rejected.

  • Its Status will show as Rejected in the Submissions table.

  • To try again, update your workflow accordingly before submitting another request to publish it.

Search for a workflow

When searching for a workflow, you can filter what workflows are displayed in the table by:

  • Entering text or keywords in the Search field to find workflows by their name.

  • Selecting one or more product integrations from the Integration drop-down list.

  • Selecting one or more types in the Authorship Type drop-down list: Cisco Managed, Cisco Verified, Community.

  • Selecting one or more intended uses of the workflow from the Intent drop-down list: Incident Response, Pivot Menu.

On the Explore tab, you can also sort the workflows shown by the order of their average rating, either from high to low or from low to high.

On the Submissions tab, you can also filter the table by status of the request, such as Saved, Submitted, Published, Unpublished, or Rejected.

Update an installed workflow

When a workflow configuration or object gets updated in Exchange, you can replace the workflow installed in your tenant with its newer version.

On the Exchange page, next to the Installed tab, a message shows how many of your installed workflows have an updated version available in Exchange.

note.svg

Any modifications you may have done to the installed workflow, such as adding targets, variables, or actions, will be lost when the installed workflow is overwritten with the newer version. If you want to retain your modifications, duplicate the workflow (and any sub-workflows) first, so while the original gets overwritten, the copy remains intact.

  1. In the top navigation bar, select app-launcher.jpg.

  2. Under Platform, select Workflows.

  3. From the left navigation, select Exchange.

  4. Select the Installed tab.

  5. Find a workflow with an Update Available, and select Update.

  6. Alternatively, select the Explore tab, and select Update on the workflow card.

  7. Select Overwrite installed version to proceed with updating the selected objects. Along with the new changes, your existing configuration (target, account key, and variable values) is retained and carried over into the wizard, where you can make additional modifications to objects as needed before completing the installation of the updated workflow.

Automate a workflow

If the workflow was published to Exchange with an automation rule configured:

  1. After the workflow installation is successful, select Automate it. The workflow is then validated and locked.

  2. The install workflow panel shows the rule associated with this workflow, along with any targets and account keys being used with this workflow.

  3. You can select View in Workflows to go to the All Workflows tab, where the status of the workflow will be either Import in Progress or Import Completed.

  4. In the workflow properties, the rule type and name appear in the Automation Rules section.

If you want to automate the execution of this workflow by adding an automation rule to it now:

  1. After the workflow installation is successful, select Automate it. The workflow is then validated and unlocked.

  2. Select the type of automation rule from Automation Rule Type.

  3. Choose an automation rule from Automation Rule Name, or select Add New to create a new rule.

  4. Select Submit. The workflow is then validated and locked.

  5. The install workflow panel shows the rule associated with this workflow, along with any targets and account keys being used with this workflow.

  6. You can select View in Workflows to go to the All Workflows tab, where the status of the workflow will be either Import in Progress or Import Completed.

  7. In the workflow properties, the rule type and name appear in the Automation Rules section.

Install a workflow

You must be signed in to Workflows as an administrator to install workflows from Exchange.

  1. In the top navigation bar, select app-launcher.jpg.

  2. Under Platform, select Workflows.

  3. From the left navigation, select Exchange.

  4. Select the Explore tab.

  5. Find the workflow you want to install, and select Learn More.

  6. Review the workflow information page. Read the Description and make a note of any additional requirements to install the workflow. If necessary, configure those items before you install the workflow.

  7. Check the check boxes beside the object types you want to configure or update during the installation and select Install.

    • If a workflow uses multiple objects of any type and you uncheck the box for one object, all objects of that type will also be unchecked.

    • If you’re installing a workflow where some or all of the objects already exist on the tenant, the information for those items will be populated in the wizard.

    • If a workflow is configured to use a target group, the wizard will display the target types, conditions, and matched targets. The individual targets in the target group must be configured before you install the new workflow; the target types and conditions for the target group cannot be modified in the wizard. After the install completes, you can view or modify the target group details in the workflow properties.

  8. To bypass configuring all of the workflow objects, select Skip All. You can also select Skip on the individual items that you do not want to configure. You can configure the workflow objects later from the Workflow Editor.

  9. Enter the values for the Account Keys, if any, and select Next.

  10. Enter the values for the Targets, if any, and select Next.

  11. Enter the values for the Variables, if any, and select Next.

  12. Installation successful! This workflow may come with an automation rule already configured, or you may want to add an automation rule to it now.

In some cases, the workflow was installed, but was not successfully validated. The validation warnings must be addressed before the workflow can be executed.

  1. Select View in Workflows to go to the All Workflows tab.

  2. Open the workflow in the Workflow Editor, and complete any remaining workflow or activity properties that are required.

  3. Select Validate to ensure that the workflow has the required data to run successfully.

If the install fails or you want to install a clean version of the workflow:

  1. Delete the existing version of the workflow, any sub-workflows, and runs on the Workflows page.

  2. Reinstall the workflow.

  3. If the workflow exists on your tenant in a valid state, or if any associated sub-workflows or runs still exist, you’ll receive an error when you select Install.

Rate a workflow

When browsing workflows in the Workflows > Exchange > Explore tab, each workflow card displays its average rating and the total number of ratings received.

Use the Sort by Rating drop-down to arrange the workflows on the page from high to low or from low to high.

Give a workflow that you’ve installed from Exchange a rating (or adjust it) by selecting Learn More on its card. Under the name of the workflow, select a rating from 1 to 5 stars.

Uninstall a workflow

You must be signed in to Automation as an administrator to uninstall a workflow that you’ve previously installed from Exchange, which will remove it from your tenant.

  1. In the top navigation bar, select app-launcher.jpg.

  2. Under Platform, select Workflows.

  3. From the left navigation, select Exchange.

  4. Select either the Explore or Installed tab.

  5. Find the workflow you want to remove, then select Uninstall under Actions.

  6. Cancel or confirm the removal of the installed workflow.
    Any sub-workflows would also be removed, unless they’re being used by other workflows.

Run monitoring

View the Run Monitoring page to inspect previous executions of workflows and atomics in your environment.

By default, run data for parent workflows is retained for 90 days. Optionally, you can purchase an additional data retention period of 180 or 365 days. However, run data for any nested activities such as atomics and sub-workflows is retained for only 30 days. These limits are currently in place to optimize system performance.

Display workflow runs

When you first access the Run Monitoring page, you’ll see workflow runs from the most recent up to one month ago, as the default date/time range is set to one month. To find specific runs:

  • Enter a full or partial workflow name in the Type to search workflows text box.

  • Select the checkboxes next to the run statuses you want to view, such as:

    • Created - Workflow created and validated, but not yet run.

    • Running - Workflow is currently running and not yet complete.

    • Waiting for Event - Workflow is waiting for an event or user input.

    • Paused - Workflow paused by the user during execution.

    • Success - Workflow completed successfully.

    • Canceled - Workflow was manually canceled during execution.

    • Failed - Workflow did not complete successfully.

    • Workflow timeout - Workflow exceeded the time limit and was automatically terminated.

You can also filter runs by a custom time range if needed; by default, results show runs from the past month.

To delete a run, click on a run to open the Run Properties drawer on the right, then click the ellipsis next to the run name and select Delete.

Tasks

Tasks enable your workflows to ask for user input before taking an action. Tasks are most commonly used to request approvals for things such as automated remediation. However, they can also be used to ask other questions such as which subnet to add a new virtual machine to.

Approvals

Approval tasks are listed in the Approvals tab.

Tasks can typically be created using the Request Approval activity. In the Workflow Editor, go to Activities and look under Task for Request Approval.

After creation, their status is monitored using an Approval task rule. A workflow can create an approval task and wait for it to be acted upon or it can create an approval task for another workflow to act on later.

Under a task’s Actions, you can choose to Approve or Reject the request.

The maximum number of approval tasks (in the Created, Pending, or Due soon status) allowed is 500 per organization.

Request Approval activity

Use the Request Approval activity to ask the user for approval during the execution of the workflow. The workflow will pause and wait for the user to respond or resume after the request expires.

Creating an approval task will notify the assignees through the Action Required: Task Pending notification in the Workspace area that they have been assigned a task and provide a link to review the task and approve or reject the request.

To take action when the task is completed, use an Approval Task Rule to check conditions against the task results and run an assigned workflow.

You can view the configured tasks on the Tasks page and results of workflow executions on the Runs page.

Enter these properties to use this activity:

  • General

    • Display Name - Enter a display name for the activity. This name is what’s displayed for the activity in the Workflow Editor.

    • Description - Enter a meaningful description.

    • Continue Workflow Execution On Failure - Check this check box to continue the workflow if this activity fails (optional).

    • Skip activity execution - Check this check box to bypass running the activity during the workflow execution (optional).

  • Add approval assignee(s) - By default, the assignee is the user who executes the workflow, unless specified differently below:

    • Add by role(s) - You can select that all administrators and/or incident responders in your organization will be prompted.

    • Add by email address(es) - Click ADD and enter the email address of individuals who will be prompted with this task.

  • Add approval title and body text

    • Approval title - Enter a title for the request. This will become the name displayed in the tasks table.

    • Body text - Enter the text to be displayed in the body of the request.

  • Add Form Elements - For a Checkbox form element where the user may check the box:

    • Checkbox Label - Enter a label for this check box.

  • Advanced Configuration - Show advanced configuration options:

    • Choose to use either the default approval choices (Approve or Reject) or a custom array.

    • Approval requestor - Enter the email address of the person or variable reference requesting the approval. May use the default variable reference.

    • Approval owner - Enter the email address of the person or variable reference who owns the request (often the same as the requestor). May use the default variable reference.

    • Minimum number of approvals - The minimum number of approvals required to approve this request.

    • Priority - High, Normal, or Low

    • Set approval due date

      • Specified Date - Enter the specific date of when the request is due.

      • Relative Time - Enter the duration or amount of time that elapses before the request is due (how much time the assignee is given to answer) and what unit the time is measured in.

    • Set expiration date

      • Specified Date - Enter the specific date of when the request expires.

      • Relative Time - Enter the duration or amount of time that elapses before the request expires (how much time the assignee is given to answer) and what unit the time is measured in.

    • Expiration Status - Enter the status that will be displayed after the request has expired.

Approval task rule

The Approval Task rule allows you to trigger a workflow when an approval task is acted upon. This allows you to have one workflow generate approval tasks and another workflow handle when they are completed.

There are certain considerations when using two workflows versus using the Request Approval activity within a single workflow:

  • The workflow that generates the approval task does not have to remain in Waiting For Event status until the task is acted upon; it can complete normally and end.

  • A single workflow can generate multiple approval tasks and the task response workflow will act on them individually as they are completed.

  • The workflow triggered by the completed task will not have access to any variables from the workflow that created the task. You need to use global variables or an external database to keep track of data between workflow instances.

Create new approval task rule

  1. In the General section, enter this information:

    • Type - Approval Task Rule

    • Title - A unique display name for the rule.

    • Description - Text that describes the rule, such as what it will trigger.

  2. The toggle is switched to on by default, so when left on, the rule is enabled and the workflow can be executed. If you want to create the rule but prevent it from triggering your workflow to run, switch the Automation rule is on toggle off to disable the rule. This is useful for testing and debugging purposes.

  3. In the Conditions section, specify the condition or conditions that determine which tasks will trigger the workflow:

    1. Property - Click the variable browser icon and choose the variable.

    2. Comparison - Click the drop-down list and choose the operator.

    3. Value - Click the drop-down list or enter the desired value, depending on the data type.
      You can click the ellipsis (…​) icon and either reset or delete a condition.

  4. If you add more than one condition, choose one of the following options:

    • ALL of these conditions must be met - The workflow will be triggered only if every condition is met (logical AND operator).

    • ANY of these conditions can be met - The workflow will be triggered if any of the conditions is met (inclusive OR operator).

    • Advanced - Click the operator drop-down to choose any combination of operators, in which case, it’s processed sequentially, top-to-bottom.
      For example: {[(condition1 AND condition2) OR condition3] AND condition4}

  5. Configure a workflow to associate with this rule.

    • In the Apply to selected workflows section, select the Select workflow drop-down and select a valid workflow or enter its name.

      note.svg

      Ensure that targets are pre-selected within the workflow. You can configure specific targets using the Target settings in the Workflow Editor.

    • Only a non-atomic workflow can be associated to the rule directly; custom and system atomic workflows cannot.

    • The most relevant workflows to this type of rule are shown starting at the top of the drop-down list.

    • Out-of-box system workflows are prefixed with a Cisco icon.

    • Depending on the workflow, enter the parameter data as needed. If the workflow has input variables, you can click the variable browser icon and select event input/output variables, which enable you to provide trigger-related values to the input variables as a reference.

    • To delete a workflow, click the (Trash Can) icon next to it.

    • By default, the workflow is on and enabled. To disable it, click the toggle switch to off.

  6. To include additional workflows, click Add another workflow.

    • Multiple workflows will be executed in parallel, not sequentially.

    • To delete a workflow, click the trash icon next to it.

    • If you delete a workflow from here, the actual workflow itself does not get deleted, only its association with this rule is removed. In the workflow’s properties, this rule would no longer appear as a trigger.

  7. Select Save, and a trigger for this rule is automatically added to the associated workflow.

Prompts

Prompt tasks are listed in the Prompts tab.

You can also create tasks using the Create a prompt activity. In the Workflow Editor, go to Activities and look under Task for Create Prompt. During the workflow execution, the activity will prompt the user for information.

The Status of the task shows if there is still action required to complete the task and whether the prompt was answered by the assignee before the time duration expired.

Under a task’s Actions, you can View Run to see the results.

The maximum number of prompt tasks (in the Action required status) allowed is 500 per organization.

Create a prompt

Use the Create Prompt activity to prompt the user for information or complete a task separate from approval during the execution of the workflow. The workflow will pause until the user responds or the prompt expires.

When a prompt task is created, the assigned user(s) or workflow initiator will receive an inline notification about pending user tasks in the Workflow Editor.

Select View Tasks to review the pending tasks and provide the necessary information to continue the workflow.

  1. In the top navigation bar, select app-launcher.jpg.

  2. Under Platform, select Workflows.
    The Workspace tab should open, by default.

  3. Select Create.

  4. Choose a type according to the intent of this workflow, then select Continue.

  5. Enter a name for the workflow, then select Continue.

  6. In the Properties panel of the Workflow Editor, define the workflow properties.

  7. From the Activities panel, search for Create Prompt activity.

  8. Drag and drop Create Prompt onto the canvas.

  9. Enter these properties:

    • General

      • Display Name - Enter a display name for the activity. This name is what’s displayed for the activity in the Workflow Editor.

      • Description - Enter a meaningful description.

      • Continue Workflow Execution On Failure - Check this check box to continue the workflow if this activity fails (optional).

      • Skip activity execution - Check this check box to bypass running the activity during the workflow execution (optional).

    • Add Assignees

      • Add by role(s) - You can select that all administrators and/or incident responders in your organization will be prompted.

      • Add by email address(es) - Select ADD and enter the email address of individuals who will be prompted with this task.

    • Add Form Elements: For a Text form element where the user may check the box:

      • Checkbox Label - Enter a label for this check box.

    • Add Form Elements - For a Text form where the user may check the box:

      • Text Label - Enter the text.

    • Add Form Elements - For a Dropdown Select form element where the user must select from a drop-down list:

      • Allow multi-select - Set whether or not the user can select more than one option in the list.

      • Dropdown Select Label - Enter a label to name this drop-down list.

      • Dropdown Select Options Array - Click the Variable Reference icon to choose the array of options to select from in the list.

      • Dropdown Option Label Key - If an object type array is chosen above, this field appears for you to choose the key of the key-value pair.

    • What do you want the prompt to say?

      • Prompt Title - Enter a title for the prompt. This will become the name displayed in the prompt tasks table.

      • Prompt Body Text - Enter the text to be displayed in the body of the prompt.

    • Advanced Configuration - Show advanced configuration options:

      • Prompt Requestor - Enter the email address of the person or variable reference requesting the prompt for information.

      • Prompt Owner - Enter the email address of the person or variable reference who owns the request (often the same as the requestor).

      • Set Prompt Expiration Date

        • Duration - Enter the amount of time that elapses before the prompt expires (how much time the assignee is given to answer).

        • Time Units - Choose what unit the time is measured in.

Targets

Targets are the systems and resources a workflow is able to communicate with. They come in a variety of types depending on the product or platform you want to connect to.

note.svg

If you have access to multiple Meraki organizations, please note that workflows and targets created in one organization are not automatically shared with, or available in, other organizations. To execute workflows in a different organization, you must configure a separate target using a manual API key specific to that organization.

  • Default targets - The Meraki target is created by default when an Automation instance is provisioned

  • Target groups - Allow your workflows to dynamically pick one or more targets from groups at runtime, which can contain multiple targets of the same type or a mix of different target types.

  • Remote targets - Automation runs in a public cloud, which means that any target you want your workflows to communicate with must be accessible from the public internet. For on-premises targets that do not have direct access to the public internet, if you want to integrate the on-premises product into a workflow, use the Automation Remote virtual appliance to bridge the gap.

  • Account Keys: Account keys are the credentials used when communicating with targets.

The Status column shows whether the target is valid or invalid, such as when its corresponding integration has been deleted.

In the Actions column, select Used by to display the objects such as workflows that use this target.

The maximum number of targets allowed is 300 per organization, not including the default targets generated by the system.

The maximum number of target groups allowed is 50 per organization.

Create a target

Targets are the systems and resources that a workflow can communicate with, enabling automation across a variety of products and platforms.

note.svg

If you have access to multiple Meraki organizations, please note that workflows and targets created in one organization are not automatically shared with, or available in, other organizations. To execute workflows in a different organization, you must configure a separate target using a manual API key specific to that organization.

  1. Open the New Target page:

    1. In the top navigation bar, select app-launcher.jpg.

    2. Under Platform, select Workflows.

    3. From the left navigation, select Targets.

    4. Select New target.

  2. Enter the required information for a new target:

    1. Target Type
      See Target Types for the list of supported targets on workflows.

    2. Display Name and an optional Description

    3. Default Account Keys: Select an existing account key or select Add New to create a new account key.

    4. Remote Keys: Select an existing remote key, or add a new one if connecting to an on-premises target that is not accessible from the public internet.

    5. In the HTTPS area, enter this information:

      • Protocol - Choose HTTP or HTTPS.

      • Host/IP Address - Enter the hostname or IP address of the target endpoint you want to connect to.

      • Port - Specify the network port used to connect to the target.

      • Disable Server Certificate Validation - Check the check box to disable server certification validation on the endpoint.

    6. In the Proxy area, enter this information:

      • Your proxy server’s URL, username, and password.

      • Proxy Bypass List: Allows you to specify which hosts to exclude from the proxy.
        Select the Ignore Proxy toggle to display or hide the proxy settings.

  3. Select Save.

Create a target group

Target groups allow you to provide collections of targets to use in a workflow. The workflow and its activities can then dynamically select targets from within that group during workflow execution. The targets within the group can all be the same type or be a mix of different types.

  1. Open the New Target Group page:

    1. In the top navigation bar, select app-launcher.jpg.

    2. Under Platform, select Workflows.

    3. From the left navigation, select Targets.

    4. Select Target Groups > New target group.

  2. Enter a unique display name for the target group and a brief description.

  3. In the Selected Targets area, click Add target type.

  4. Select a target type and specify whether to include all targets of this type.

  5. To include individual targets, select them from the Targets drop-down list.

  6. If necessary, add conditions.

  7. Select OK.

Create a remote target

Remote target is a virtual appliance that acts as a secure communication bridge between your cloud-hosted workflows and on-premises or private network resources that do not have direct internet access. Use the following steps to create and deploy a remote target in your environment. For more information on Remote Target, refer to Create a New Remote.

To configure a new remote target:

  1. Prepare your VMware environment.
    Ensure you have the necessary privileges and familiarity with creating and managing virtual resources in VMware vSphere. Setting up the Remote Target requires deploying an OVA file and performing initial configuration within vCenter. If you encounter any issues during setup, contact your VMware administrator or VMware Support for assistance.

  2. Create a remote in your automation tenant.
    Log in to your Automation dashboard and create a new remote.

  3. Configure and deploy the remote target.

    1. Generate the configuration file from the Automation Dashboard.

    2. Download remotePackage.zip.

    3. Download the OVA file.

    4. Deploy it using VMware vSphere.
      During the initial setup in VMware vCenter, copy and paste the necessary text file from remotePackage.zip when prompted.

      After deployment, allow up to 10 minutes for the Remote Target to complete its registration with the cloud. Refer to Configure and Deploy the Remote Target Virtual Appliance.

  4. Configure targets to use the newly created remote target. After the Remote Target is deployed and operational, configure your on-premises targets to route their automation workflows through this newly established Remote Target. Refer to Configure Target to Use the Remote Target.

Create a New Remote

note.svg

Setting up the Automation Remote virtual appliance requires advanced understanding of how to create and manage resources in VMware. If you encounter issues within the vSphere client, contact an administrator in your organization or VMware support.

To configure a new Automation Remote virtual appliance, you must first create the Remote in your Automation tenant. You can then download the appliance and deploy it using VMware vSphere. After you deploy the Remote from VMware, configure targets to use the Remote.

Automation Remote supports the following target types:

  • HTTP Endpoint

  • Terminal Endpoint

  • Unix/Linux Endpoint

The maximum number of Remotes you’re allowed to create is 20.

Perform the following steps to create a new Remote on your Automation tenant:

note.svg

In some cases, the default subnets may sometimes collide with your existing network. In such a scenario, you may need to override the default values with whatever subnet you have available. However, any changes you make to the default subnets are permanent and cannot be reversed without installing a new appliance.

  1. Open the New Account Key page:

    1. In the top navigation bar, select app-launcher.jpg.

    2. Under Platform, select Workflows.

    3. From the left navigation, select Targets.

    4. Select Remote Targets > New target.

  2. Complete the New Target page:

    1. Enter a meaningful Display Name and optional Description.

    2. In Remote Details, set DHCP or Static IP to set your DNS type.

      If you select Static IP, provide this information:

      • IP address in CIDR notation (for example: 192.168.1.100/24)

      • List of DNS servers (for example: 192.168.1.1,192.168.1.2)

      • Default gateway (for example: 192.168.1.1)

    3. If a proxy is required for the Remote to access the internet, select Requires Proxy toggle and enter the Proxy Address (only SOCKS5 proxies are supported).

    4. If you want to override the default subnets and provide private subnets to start the Remote, select Show advanced options and enter the Remote Cluster Subnet and Remote Service Subnet that you want to use instead of the defaults.

  3. Select Save.

The new Remote will be displayed in the list with a status of Not Connected.

Download the Remote Configuration File

Configuration information is unique to each Remote. After you create a Remote in Automation, generate and download its configuration file.

  1. In the Targets > Remote Targets page, locate the newly created Remote, click the ellipsis (…​) for the newly created Remote, then select Connect.

  2. Select Generate Package.

A remotePackage.zip file with the Remote configuration will be downloaded to your system. Unzip this file; its remoteconfig.txt will be used later.

Configure and Deploy the Remote Target Virtual Appliance

After you create a Remote and download its configuration file, you will download the virtual appliance OVA and use VMware vSphere to deploy it and apply the configuration.

note.svg

The current OVA includes support for Catalyst Center, Catalyst SD-WAN, Cisco ISE, Cisco FMC, and NetBox.

  1. In the Targets > Remote Targets page, select Download appliance to download the newest version of the Remote appliance.

  2. To verify that the OVA is complete and not corrupted, compare its file hash against the following:

    Filename SHA256 Hash

    cisco-automation-remote-2.12.ova

    e33ee7a8ed9ed6c3f382e8612e52fbfcb35320ad2e6a5812faa607ef6450fc50

  3. In your VMware vSphere client, right-click the folder you want to deploy the Remote in, and select Deploy OVF Template.

  4. Select Local file, and then select Choose Files. Navigate to the Remote OVA you downloaded and select it.

  5. Select Next.

  6. Give the virtual appliance a unique name, confirm the location for the virtual machine, and select Next.

  7. Select the compute resource where the virtual appliance will be deployed, then select Next.

  8. Review the details of the deployment, then select Next.

  9. In the list of datastores, choose the datastore you want to use for the virtual appliance, then select Next.

    We recommend a minimum of 30 GB of available disk space for an Automation Remote.

  10. For each Source Network, select Destination Network, select the network where you want to deploy the virtual appliance, then select Next.

  11. In Customize Template or Customize vApp properties, provide this information:

    • Unique ID and hostname for the virtual appliance.

    • (Optional) SSH public key for SSH access to the appliance (refer to Generate an SSH Key Pair below).

    • Set Encoded user-data to the contents of remoteconfig.txt (from the remotePackage.zip configuration file above).

    • Set a Default user’s password for access to the virtual appliance console (username: ubuntu).

      To avoid a setup failure, your password must be at least 14 characters long and must:

    • Contain at least:

      • 1 uppercase letter

      • 1 lowercase letter

      • 1 number

      • 1 special character

    • Not contain:

      • More than 3 identical characters in a row (i.e., 'aaa')

      • More than 3 sequential characters (i.e., '123', 'abc')

      • Your username

      • Common dictionary words

  12. Select Next.

  13. Review all of the virtual appliance details, then select Finish.

  14. After the virtual appliance deployment completes, select Power On to start the appliance.

    When the appliance is online, the Status of the Remote should change from Not Connected to Connected on the Targets > Remote Targets page.

note.svg

A newly deployed Remote Target may take up to 10 minutes to show as connected.

(Optional) Define NTP Servers

After the deployment, you can configure the Remote Target to use custom NTP servers. If you are unsure of the settings to use, contact your network administrator.

  1. Sign in to your Remote Target. You can either:

    • Open a console to the Remote Target in vSphere and sign in with your password.

    • SSH to the Remote Target using the key pair you created during setup.

  2. Open the /etc/chrony/chrony.conf file and change the NTP servers to your preferred servers.

  3. Save and close the file.

  4. Run this command to restart the NTP service and verify that the time is correct:

    systemctl restart chronyd ; watch chronyc tracking

Generate an SSH Key Pair

If you want to use SSH to access your Remote Target, you must generate a key pair for authentication. You can use any key pair that is valid for a standard Ubuntu ~/.ssh/authorized_keys file (for example, RSA or ED25519).

Use these examples to generate a default RSA key pair.

Linux/MacOS

  1. Open a terminal and enter this command:

    ssh-keygen -t rsa -b 4096 -f /path/to/output/keypair

    (for a 4096-bit RSA key)

  2. If you want to use a passphrase, enter the passphrase and confirm it. If not, press Enter twice.

A public and private key will be generated at the path you provided:

  • keypair will contain the private key

  • keypair.pub will contain the public key

Windows

Use the PuTTygen utility to generate a keypair:

  1. Download PuTTygen. Use the file puttygen.exe located under Alternative binary files.

  2. Run puttygen.exe.

  3. To use a passphrase for your key pair, enter it in Key passphrase and Confirm passphrase.

  4. Select the type of key and key length (we recommend a minimum 2048-bit RSA key).

  5. Select Generate.

  6. Use Save public key and Save private key to export the keys.

Configure Target to Use the Remote Target

Configure your on-premises targets to use the Remote Target.

  1. In the top navigation bar, select app-launcher.jpg.

  2. Under Platform, select Workflows.

  3. From the left navigation, select Targets.
    The Targets tab is selected, by default.

  4. Select the target you want to add a remote to (or create a new target).

  5. In the Remote section, select the Remote Target you want to use with this target.

  6. Select Save.

Account keys

Account keys is the term Automation uses for credentials used when communicating with targets. Account keys come in a variety of types that correspond to the types of targets that are available. Targets are not required to have account keys, but for targets that require authentication, the key type must match the target type.

Account key instances can be shared across targets and workflows. For example, if a single set of credentials can be used to access a set of target network devices, you only need to create one account key that can be used for any of the targets. When it is time to change the credentials, you can go to the Account Keys list and edit the single instance to update the credentials throughout your targets and workflows.

The maximum number of account keys allowed is 300 per organization.

Key types

Account keys come in a variety of types depending on the type of target. The account key type must match the target used. The following table includes all out-of-box account keys and their associated target types.

Account Key Type Target Types

Ansible Tower OAuth Credentials

Ansible Tower Endpoint

Azure AI Credentials

Azure AI Endpoint

OpenAI Credentials

OpenAI Endpoint

Catalyst Center Basic Authentication

Used for connecting to Catalyst Center

Catalystsdwan Credentials

Used for connecting to Catalyst SDWAN

Cisco ISE Basic Authentication

Used for connecting to Cisco ISE

Email Credentials

IMAP Endpoint, POP3 Endpoint, SMTP Endpoint

Git Password-Based Credentials

Used for connecting to Git repositories.

Git Token-Based Credentials

Used for connecting to Git repositories.

HTTP Basic Authentication

HTTP Endpoint

HTTP Client Certificate Authentication

HTTP Endpoint

HTTP Signature Authentication

HTTP Endpoint

HTTP Bearer Authentication

HTTP Endpoint

HTTP Custom Header Authentication

HTTP Endpoint

Infoblox Token-Based Credentials

Infoblox Endpoint Target

JDBC Login Credentials

JDBC Database Server

Meraki Credentials

Meraki Endpoint

Microsoft Windows Credentials

Microsoft Windows Endpoint

OAuth2 Microsoft Graph Credentials

Microsoft Graph Endpoint

SNMP Credentials

SNMP Endpoint

Terminal Key-Based Credentials

Terminal Endpoint, Terraform Endpoint, Unix/Linux Endpoint

Terminal Password-Based Credentials

Terminal Endpoint, Terraform Endpoint, Unix/Linux Endpoint

Create an account key

  1. Open the New Account Key page:

    1. In the top navigation bar, select app-launcher.jpg.

    2. Under Platform, select Workflows.

    3. From the left navigation, select Targets.

    4. Select Account Keys > New account key.

  2. Enter this information for the account key:

    • Key type

    • Name and description

    • Credentials: The credentials you need to enter vary, depending on the selected key type.

  3. Select Save.

Variables

You can have global variables that are available to all of your workflows or define variables within a workflow. Variables can be used to store data between workflow executions or to share data between different workflows. Variables can be used to store and pass information between activities in a workflow.

You can view and create global variables from the Variables page.

NOTE:

  • The variable size for all variable types (Global, Environment, Local, Static, Input, Array Type, Object Type, and Table Type variables) is limited to 1 MB. If a user attempts to create a variable with a size greater than 1 MB, Automation will return an error.

  • The size of the Large String workflow variable type is limited to 10 MB.

Global variables

Global variables are useful when you want to store information between runs of a workflow or share information between different workflows.

Workflows do not have any concept of persistence. For example, the second time a workflow runs, it does not carry over data about the first time it ran. Global variables can be used to bridge this gap by storing information that persists.

In some instances, you may want multiple workflows to share information. A common example is an API key or Webex Teams room name.

The maximum number allowed of global and environmental variables combined is 300 per organization.

Create a global variable

  1. Open the New Variable page:

    1. In the top navigation bar, select app-launcher.jpg.

    2. Under Platform, select Workflows.

    3. From the left navigation, select Variables.

    4. Select New variable.

  2. Select a data type for the variable.

  3. In the General section, enter this information for the variable:

  4. Display Name and optional Description

  5. The variable’s Scope:

    • Environment - Variables that store data specific to the environment that can be used across different workflows.

    • Global - Variables that store data that will persist across workflow runs or between different workflows.

  6. (Optional) String Type: If you select a string type, enter a value in the next field. If you intend to have the variable data updated by an activity in the workflow, leave this field blank.

  7. Select Save.

Usage

Using a global variable within a workflow is the same as using any other variable. In the Workflow Editor properties for an activity, select the Variable Reference icon in a field and use the variable browser to select the variable you want to use.

You can also use the Set Variables activity in a workflow to update the value of a global variable within the workflow.

Workflow variables

You can define variables within a workflow to store and pass information between activities in a workflow. In the workflow editor properties, under Variables, select Add variable.

You can define the following types of variables within a workflow or atomic action:

  • Input

  • Output

  • Local

  • Static

Each variable type listed under Scope has a specific purpose.

The maximum number of variables allowed in a workflow is 100.

Input variables

Input variables allow your workflow or atomic action to consume information when they are executed. If a workflow has input variables and you click Run, you will be asked to provide values for those variables before the workflow runs.

If an atomic action has input variables, you will be able to provide their values when editing its properties within a workflow.

Input variables can be optional or required. If they are required, the workflow will not run without input. If a variable is required for an atomic action, the workflow will not validate unless input is provided.

Check the Display on install wizard check box if you want users to be able to enter a value for this input variable during the installation of the parent workflow from the Exchange.

Output variables

Output variables can be used by workflows and are most commonly seen in atomic actions. Many atomic actions consume input using input variables, perform a function, and then produce output in output variables. Output variables are available after an atomic action or sub-workflow runs and are usually used by subsequent activities.

Local variables

Local variables only exist within an individual workflow or atomic action, and any values assigned to them do not persist across workflow runs.

If you do not provide local variable values to a workflow when it starts, the values are not accessible outside of the workflow after it ends. You can only get or set these values within the workflow itself. Local variables are useful as placeholders for assembling text for Webex Teams messages, for example.

Static variables

Static variables only exist within an individual workflow. They are not available to other workflows.

A static variable has a pre-set value that can be modified with a Set Variables activity. The new value defined by the Set Variables activity persists across workflow runs.

Workflow result

You can update these two variables to provide feedback to the workflow user with information about the workflow execution:

  • Workflow Result - Free-text property (can also be written in Markdown language) to communicate the results of the run and provide context, such as the "Investigation completed" string.

    • Needs to be explicitly set in all the cases where the workflow can end.

    • We recommend that you append these updates to a local variable as the workflow progresses.

  • Workflow Result Code - Auto-populated string that indicates the outcome of the workflow.

    • Normally, the system derives this value based on the workflow result and implicitly sets it as follows:

      • Started - the workflow is running

      • Waiting-for-prompt-response

      • Start-error, Internal-error, Workflow-errored - the workflow failed

      • Partially-completed - the workflow did not fail, but at least one observable task did not succeed

      • Completed successfully - the workflow did not fail, and all observable tasks succeeded

      • Completed unsuccessfully - the workflow did not fail, but all observable tasks failed

  • As long as the workflow does not fail and completes, you have the option to override its result code by explicitly setting it as needed.

Automation rules

Rules define the conditions that trigger a workflow to execute. To add a trigger to a workflow, select Rules > Automation Rules in the navigation menu.

note.svg

Before configuring automation rules, ensure that the workflow is valid. Only workflows in a valid state can be executed manually or triggered by an event.

The Rules page includes these tabs:

  • Automation Rules

    • Configure a rule that determines when a workflow is executed, such as when a particular event occurs or according to a set timetable. Add optional conditions, and if they’re met, any workflow(s) you’ve associated to use that rule as a trigger will be executed.

    • Examples of events include an approval task being approved, an email arriving in an inbox, a notification of a new incident, and a webhook being received. Use rules to watch for patterns in these services, thereby enabling policy-driven automation.

  • History

    • Shows a log of events that occurred and triggered any of your matching automation rules during the past 72 hours.

    • Table columns show the event name, type of event, number of automation rules that matched, and when the event occurred.

    • Search for and filter events by name, type, and timeframe during which they occurred (the past 24, 48, or 72 hours).

    • Click an event to slide out a drawer with additional details such as the raw event data and links to the matched rules and workflows executed (runs).

    • Events may not appear in the table if a per-day or per-minute rate limit was reached.

  • Calendars

    • Calendars define a collection of days and times when a workflow should be executed.

    • A time range calendar can be used to trigger a workflow on pre-defined days and times.

  • Webhooks

    • Webhooks allow you to push information from external platforms to Automation workflows.

    • Instead of configuring your workflow to reach out to an API to check for events, you can configure a webhook to listen for incoming data and then trigger a workflow through an automation rule when data is received.

Add an automation rule

  1. Open the New Automation Rule page:

    1. In the top navigation bar, select app-launcher.jpg.

    2. Under Platform, select Workflows.

    3. From the left navigation, select Rules.

    4. With Automation Rules selected, select Add automation rule.

  2. In the General section:

    1. Select the type of rule you want to add:

      • Approval Task Rule

      • Email Rule

      • Schedule Rule

      • Webhook Rule

    2. Enter a name for the rule.

    3. Ensure the rule is toggled on.

  3. You can limit when a rule’s workflows would be run by adding a condition to the rule in which you specify a calendar. Then, only events that happen within (or outside of) this window and pattern of time can trigger the rule to execute its associated workflows. When creating or editing the rule, add a condition with the following:

    • Property - Choose Event Received Time.

    • Comparison - Choose either During or Not During to check whether the date-time is within or outside of the parameters defined in the calendar.

    • Value - Choose a previously configured calendar or create a new one.

      note.svg

      When configuring rules, keep in mind that it is possible for a single event to trigger multiple rules, if the conditions in those rules are met. We recommend that you configure exclusive rules to avoid having multiple rules and their associated workflows be triggered by the same event.

  4. Select the workflows you want to apply this rule to, then select Save.

Webhooks

Webhooks allow you to push information from external sources to notify Cisco Workflows that something happened. Instead of using API requests, you can use a webhook to listen for that incoming data and trigger a Webhook rule to execute its associated workflow(s) when the data is received.

To use webhooks in Automation, verify that your request uses a supported Content-Type header. Then, create the webhook and a Webhook rule. Finally, associate a workflow to the rule, and add an activity to the workflow that executes when it’s triggered. The incoming webhook will cause the rule to trigger the workflow.

Note: To ensure platform integrity, there are some rate limits set for webhooks:

  • Webhooks support an individual payload size of up to 1 MB.

  • The maximum number of webhooks allowed is 30 per organization.

  • An external event can trigger a workflow up to 10 times per minute.

Supported content-type headers

Webhooks are HTTP-based endpoints that can send an HTTP post to the webhooks URL, with or without a payload, which then can trigger a workflow. If you choose to include payload data in your request, you must use a valid content-type. The following content-type headers are supported in Automation:

  • application/json

  • application/json;charset=utf-8

  • application/x-www-form-urlencoded

  • application/xml

If you send any other type of content, the request will be rejected.

Using RequestBin to verify content-type header

You can use a website such as RequestBin to check the Content-Type header for any webhooks you want to configure.

  1. Open RequestBin. You should see an endpoint URL similar to https://enrszd3sz7aa.x.pipedream.net.

  2. Configure the product you want to send webhooks from and then send a webhook to the endpoint URL. After the source product sends a webhook, it will show up in your RequestBin.

  3. Select the request in the list on the left to view the request details on the right.

  4. Expand the Headers list and look for the Content-Type.

  5. When you create the webhook in Automation, select the same Request Content Type as the webhook Content-Type header in RequestBin.

    • If your webhook did not provide a Content-Type header, it is unlikely to work in Automation. Contact support for the source product and see if they can add the header to their webhooks.

    • If the Content-Type header does not match a supported type in Automation, the webhook will not work. Contact Cisco Support to log a request for a new Content-Type header.

Create a webhook

When you create a webhook, you will be given an HTTP endpoint where you can push events from the source product. A single webhook can be used to trigger a single workflow or multiple workflows.

  1. Open the New Webhook page:

    1. In the top navigation bar, select app-launcher.jpg.

    2. Under Platform, select Workflows.

    3. From the left navigation, select Rules.

    4. Select Webhooks > New webhook.

  2. In the General section, enter these settings for the webhook:

    • Display Name - A unique meaningful name for the webhook.

    • Description - Text that describes the webhook, such as what the incoming data will trigger.

    • Request Content Type - Select the Content-Type for your payload (incoming webhook):

      • application/json

      • application/json; charset=utf-8

      • application/x-www-form-urlencoded

      • application/xml

    • Expiry - The webhook’s expiration date. The default is one year from today.

  3. Select Save.
    The webhook you created is now listed in the Webhooks page.

  4. In the Display name column, select the webhook’s link to view the generated Webhook ID, API Key, and Webhook URL. The URL is where the source product of the webhook will push events.

You can now create a webhook rule to listen for incoming data from this webhook. This rule will be checked and used as the trigger to execute the associated workflow(s).

Trigger a webhook

To trigger a webhook, you can either configure a source product to send events to the Webhook URL or you can POST your own events using standard HTTP requests. Authentication is provided by the API key in the URL, and the request must have both Content Type and Accept headers. A request body is not required, but allows you to pass data to your workflow.

Example requests

  • POST to trigger a webhook with no request body:
    POST /webhooks/01MYFX09T0JZeDFNggAd92MlpAaWgoi?api_key=61NtR8LBuYNMtBw6bdqwPAe8oGoIzjZuFxIXt/C8/MMfKE2R6d6WDppBLWWwYdywgMqInyClmAP7qN1ePi0H6vBFgHQIa5xnaT4P9iY+02X064s1+Q== HTTP/1.1 Host: Content-Type: application/json Accept: application/json

  • POST to trigger a webhook with a JSON payload:
    POST /webhooks/01MYFX09T0JZeDFNggAd92MlpAaWgoi?api_key=61NtR8LBuYNMtBw6bdqwPAe8oGoIzjZuFxIXt/C8/MMfKE2R6d6WDppBLWWwYdywgMqInyClmAP7qN1ePi0H6vBFgHQIa5xnaT4P9iY+02X064s1+Q== HTTP/1.1 Host: Content-Type: application/json Accept: application/json Content-Length: 85 { "key": "value", "list_of_stuff": [ "item1", "item2" ] }

If your request was accepted by Automation, you will receive a 202 Accepted HTTP response with no body.

Troubleshooting

If your webhook responds with an HTTP status code other than 202, validate the following:

  • The webhook is tied to an event.

  • The webhook URL is correct, including the api_key.

  • The HTTP request type is a POST.

  • The Accept header is set to application/json.

  • The Content-Type header is set to one of the values supported by Automation. If your webhook responds with a 415 error, this indicates an incorrect or missing header.

  • If your webhook responds with an HTTP status code of 429, you may be sending too many webhooks and hitting a rate limit. External events are limited to 5,000 executions per day across all event types and up to 10 executions per minute individually.

If your webhook responds with a 202, but your workflow does not run, check the following:

  • The webhook is tied to an event and the event is configured correctly as a trigger in your workflow.

  • The workflow is in a valid state (the validation button should say Validated in the Workflow Editor).

note.svg

Webhooks created before the January 20, 2022 release require new API keys. To resolve this, edit and save the webhook and make note of the new API key. Then update any source systems with the new API key.

Need help?