Built-in workflows

FireFlow assigns each change request to a workflow that controls the change request's lifecycle, including the actions that can be performed on the change request, the behavior associated with each action, and the possible change request statuses.

Default workflow selection

In order to determine which workflow to use for a change request, FireFlow performs the following steps:

  1. FireFlow refers to the template that the requestor selected for the change request.

  2. If the template specifies a workflow, FireFlow assigns the change request to that workflow.

  3. If the template does not specify a workflow, then FireFlow refers to a set of conditions that determine which workflow should be assigned.

  4. If FireFlow fails to assign a workflow based on the set of conditions, then FireFlow assigns the change request to the default workflow.

Built-In workflow reference

FireFlow comes with the following set of built-in workflows, located under /usr/share/fireflow/local/etc/Workflows/:

Workflow

File Name

Description

Lifecycle Stages

Basic

 Basic_Config.xml

This is the default workflow, resulting in the default change request lifecycle. It is Used by traffic change requests.
  • Request
  • Plan
  • Approve
  • Implement
  • Validate
  • Match
  • Resolved
  • Audit

Standard

 Standard_Config.xml

This workflow is used by traffic change requests.

For installations older than version 6.5, this is the default workflow. Upgrading from v6.4 or below will not set the Basic workflow as the default.
  • Request
  • Plan
  • Approve
  • Implement
  • Validate
  • Match
  • Resolved
  • Audit

Generic

 Generic_Config.xml

This workflow is used for change requests that are not related to traffic. As such, no device change planning or matching of device changes to the change request are required, and these stages (Plan and Match) are omitted.
  • Request
  • Approve
  • Implement
  • Validate
  • Resolved
  • Audit

Multi-Approval

 Multi-Approval_Config.xml

This workflow is used for change requests that require approval from multiple users. It therefore includes an extra stage (Review) that is performed by a controller user.
  • Request
  • Plan
  • Approve
  • Review
  • Implement
  • Validate
  • Match
  • Resolved
  • Audit

Parallel-Approval

 Parallel-Approval_Config.xml

This workflow is used for change requests that require approval from two users in parallel. It therefore includes an extra change request approval stage called Review that is performed by a controller.
  • Request
  • Plan
  • Approve
  • Review
  • Implement
  • Validate
  • Resolved
  • Audit

Change-Object

 Change-Object_Config.xml

This workflow is used for change requests for modifying device objects.

  • Request
  • Plan
  • Approve
  • Implement
  • Validate
  • Resolved
  • Audit

Rule-Removal

 Rule-Removal_Config.xml

This workflow is used for change requests that are for removing device rules.
  • Request
  • Approve
  • Implement
  • Validate
  • Resolved

Rule-Modification

 Rule-Modification_Config.xml

This workflow is used for requests that are for modifying a rule's source, destination, service or application fields.
  • Request
  • Approve
  • Implement
  • Validate
  • Resolved

Web-Filter

 Web-Filter_Config.xml

This workflow is used for change requests that are for filtering Web connections. It is relevant for Symantec Blue CoatClosed As of A32.20 AlgoSec will no longer support adding new Symantec Blue Coat devices. Existing deployed Blue Coat devices will still be functional. devices only.
  • Request
  • Plan
  • Approve
  • Implement
  • Validate
  • Match
  • Resolved
  • Audit

IPv6-Traffic

 IPv6-Traffic_Config.xml

This workflow is used by traffic change requests with IPv6 traffic.

Note: Many automated functionalities that are provided for IPv4 traffic are not supported for the IPv6 traffic workflow.
  • Request
  • Plan
  • Approve
  • Implement
  • Validate
  • Match
  • Resolved
  • Audit

Automatic-Traffic-Change

 Automatic-Traffic-Change_Config.xml

This workflow is used by traffic change requests with "allow" traffic only. All of the lifecycle stages proceed automatically.
  • Request
  • Plan
  • Approve
  • Implement
  • Validate
  • Match
  • Resolved
  • Audit

Request-Recertification

 Request-Recertification_Config.xml

This workflow is used to determine whether an Allow rule that was added to a device policy as the result of an expired traffic change request is still relevant. If the rule is no longer relevant, a rule removal request is created to remove it.
  • Request
  • Approve
  • Implement
  • Validate
  • Resolved
  • Audit

Bulk-Rules-Addition

 Bulk-Rules-Addition_Config.xml

This workflow is used for bulk rules addition, like populating a new device.
  • Request
  • Plan
  • Implement
  • Match
  • Resolved
  • Audit

Bulk-Rule- Removal

 Bulk-Rule-Removal_Config.xml

This workflow is used for bulk rule removal.
  • Request
  • Plan
  • Implement
  • Match
  • Resolved
  • Audit

Object-Change-Multi-Device

 Object-Change-Multi-Device.xml

This workflow is used for change requests for modifying device objects on multiple devices.
  • Request
  • Plan
  • Approve
  • Implement
  • Validate
  • Resolved
  • Audit

You cannot modify the built-in workflows; however, you can create new ones as desired. For your convenience, FireFlow allows you to create variations of existing workflows (both built-in and custom ones), by duplicating the relevant workflow and then modifying it.

Furthermore, you can modify the set of conditions determining which workflow should be assigned, when the template does not specify a workflow.

Manage your workflows in VisualFlow. While workflows are XML files, we do not recommend making manual updates directly to the files, except where explicitly instructed.