Examples using VisualFlow

This topic describes several sample use cases for VisualFlow.

Remove the Notify Requestor stage

The following comprehensive example describes how to modify a copy of the Standard workflow, so that FireFlow does not wait for user acceptance after implementing a change request.

Once implementation is complete, the Network user can simply resolve the change request (or re-implement it, if an error was detected). Notification is sent to the user only upon the resolve action.

Do the following:

  1. Log in to FireFlow for configuration purposes. For details, see Log in for configuration purposes.

  2. Access VisualFlow. For details, see Get started in VisualFlow.

  3. Add a new workflow based on the Standard workflow.

    The workflow "Standard-Copy-#" is created, where # represents the copy's number.

  4. Edit the new workflow as follows:

    • Set the Name field to the workflow's name. For example, "MyStandard".
    • Set the Configuration File field to the workflow's configuration file. For example, "MyStandard".
    • Set the Default field to yes.

  5. Delete the workflow's "Notify Requestor" action.

  6. Edit the workflow's "Resolve" action as follows:

    • Set the Type field's to Reply to user, so that mail can be sent to the requestor.
    • Set the Mail content field to "Your request has been implemented. It will be closed now.".

  7. Add a "resolve" outbound action to the workflow's "Validate" status as follows:

    • Set the Display action button field to Yes, so that the "Resolve" button will appear for change requests in the "Validate" stage.
    • Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in the workflow layout.

  8. Install the workflow.

  9. Log in to the FireFlow server via SSH, using the username "root" and the related password.

  10. Restart FireFlow. For details, see Restart FireFlow.

Allow the Network Role to approve change requests

The following comprehensive example describes how to modify a copy of the Standard workflow, to allow Network users to approve change requests.

After initial planning, the change request achieves the new status "pre-check". Network users can then decide whether to approve the change request, not approve it, or send it to a Security user.

Do the following:

  1. Log in to FireFlow for configuration purposes. For details, see Log in for configuration purposes.

  2. Access VisualFlow. For details, see Get started in VisualFlow.

  3. Add a new workflow based on the Standard workflow.

    The workflow "Standard-Copy-#" is created, where # represents the copy's number.

  4. Edit the new workflow as follows:

    • Set the Name field to the workflow's name. For example, "MyStandard".
    • Set the Configuration File field to the workflow's configuration file. For example, "MyStandard".
    • Set the Default field to yes.

  5. Add a new status to the workflow as follows:

    • Set the Name field to "pre-check".
    • Set the Stage field to approve.
    • Set the Responsible role field to Network.
    • Set the Allow editing traffic fields field to yes.
    • Set the Stage still incomplete field to yes.

  6. Reorder the statuses so that the new "pre-check" status appears immediately before the "approve" status.

  7. Add a new action to the workflow as follows:

    • Set the Name field to "send_to_security".
    • Set the Type field to Change status.
    • Set the Display Name field to "Send to Security".
    • Set the Target status field to approve.
    • Set the Required action permission field to UserDefinedRight01.
    • Set the Applies to change requests of type field to Parent and Regular.
    • Set the Traffic fields required field to yes.

  8. Reorder the actions so that the new "Send to Security" action appears immediately after the "Risk Check" action.

  9. Edit the "Initial Plan" action to transition the change request to the new "pre-check" status as follows:

    Set the Target status field to pre-check.

  10. Edit the "Risk Check" action to transition the change request to the new "pre-check" status as follows:

    Set the Target status field to pre-check.

  11. Add a "risk_check" outbound action to the "pre-check" status as follows:

    • Set the Display action button when field is empty field to Request Risk Check Result, so that the "Risk Check" button will appear for change requests in the "pre-check" stage when this field is empty.
    • Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in the workflow layout.

  12. Add a "send_to_security" outbound action to the "pre-check" status as follows:

    • Set the Display action button field to Yes, so that the "Send to Security" button will appear for change requests in the "pre-check" stage.
    • Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in the workflow layout.

  13. Add an "approve" outbound action to the "pre-check" status as follows:

    • Set the Display action button field to Yes, so that the "Approve" button will appear for change requests in the "pre-check" stage.
    • Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in the workflow layout.

  14. Add a "re_plan" outbound action to the "pre-check" status as follows:

    • Set the Display Name field to "Not Approve", so that this button's name will appear for change requests in the "pre-check" stage.
    • Set the Display action button field to Yes, so that the "Not Approve" button will appear for change requests in the "pre-check" stage.
    • Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in the workflow layout.
    • Set the User confirmation needed field to No, so that this action will not trigger an "Are you sure?" pop-up for change requests in "pre-check" stage.
    • Set the Mail content field to "Your request has not been approved and needs to be re-planned", so that this text will appear in emails sent to the requestor for change requests in "pre-check" stage.

  15. Add a "re_implement" outbound action to the "pre-check" status as follows:

    Set the User confirmation needed field to No, so that this action will not trigger an "Are you sure?" pop-up for change requests in the "pre-check" stage.

  16. Delete the "Risk Check" outbound action from the "approve" status, so that the risk check button will not appear for change requests in the "Approve" stage.

  17. Assign the UserDefinedRight01 permission to the Network user role.

    Members of the Network role can now perform the "Send to Security" action.

  18. Install the workflow.

  19. Log in to the FireFlow server via SSH, using the username "root" and the related password.

  20. Restart FireFlow.

Add another Approve stage

The following comprehensive example describes how to modify a copy of the Standard workflow, by adding a second Approve stage to the lifecycle.

A new status, "second check", will be achieved after the first approve action. The second approve must then be performed by the new "High Level Security" user role.

Do the following:

  1. Log in to FireFlow for configuration purposes. For details, see Log in for configuration purposes.

  2. Add a user role as follows:

    • Set the Name field to "High Level Security".
    • Set the Description field to "High Level Security".

  3. Set the user role to inherit permissions from the security role.

  4. Access VisualFlow.

  5. Add a new workflow based on the Standard workflow.

    The workflow "Standard-Copy-#" is created, where # represents the copy's number.

  6. Edit the new workflow as follows:

    • Set the Name field to the workflow's name. For example, "MyStandard".
    • Set the Configuration File field to workflow's configuration file. For example, "MyStandard".
    • Set the Default field to yes.

  7. Add a new status for the workflow as follows:

    • Set the Name field to "second check".
    • Set the Stage field to approve.
    • Set the Responsible role field to High Level Security.
    • Set the Allow editing traffic fields field to yes.
    • Set the Stage still incomplete field to yes.

  8. Reorder the statuses so that the new "second check" status appears immediately after the "approve" status.

  9. Add an "approve" outbound action to the "second check" status as follows:

    • Set the Display action button field to Yes, so that the "Approve" button will appear for change requests in the "second check" stage.
    • Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in the workflow layout.

  10. Add a "re-plan" outbound action to the "second check" status as follows:

    • Set the Display Name field to "Reject", so that this button's name will appear for change requests in the "second check" stage.
    • Set the Display action button field to Yes, so that the "Reject" button will appear for change requests in the "second check" stage.
    • Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in the workflow layout.
    • Set the User confirmation needed field to No, so that this action will not trigger an "Are you sure?" pop-up for change requests in the "second check" stage.
    • Set the Mail content field to "Your request has been rejected and needs to be re-planned", so that this text will appear in emails sent to the requestor for change requests in the "second check" stage.

  11. Add a "re-implement" outbound action to the "second check" status as follows:

    Set the User confirmation needed field to No, so that this action will not trigger an "Are you sure?" pop-up for change requests in "second check" stage

  12. Add a new action to the workflow as follows:

    • Set the Name field to "first_approve".
    • Set the Type field to Internal comment.
    • Set the Display Name field to "First Approve".
    • Set the Target status field to second check.
    • Set the Required action permission field to UserDefinedRight02.
    • Set the Applies to change requests of type field to Parent and Regular.
    • Set the Traffic fields required field to yes.

  13. Reorder the workflow's actions, so that the new "First Approve" action immediately after the "Risk Check" action.

  14. Edit the "Approve" action as follows:

    Set the Display Name field to "Final Approve".

  15. Add a "first_approve" outbound action to the "approve" status as follows:

    • Set the Display action button field to Yes, so that the "First Approve" button will appear for change requests in the "approve" stage.
    • Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in the workflow layout.

  16. Delete the "Final Approve" outbound action from the approve status.

  17. Assign the UserDefinedRight02 permission to the Security user role.

    Members of the Security role can now perform the "First Approve" action.

  18. Install the workflow.

  19. Log in to the FireFlow server via SSH, using the username "root" and the related password.

  20. Restart FireFlow.