Skip to content

Approving Workflows

Workflows run as particular users. They execute commands on certain assets. They manipulate files and filesystems. All of these users, assets, etc. are protected resources.

The approval process allows one or more people who have access to the protected resources a workflow needs to access to grant the use of those resources to that workflow.

Submitted moving to Approved

Approval is the process of moving workflows from the submitted state to the approved state. If the approved workflow is a change to an existing workflow, then the newly approved workflow replaces the old one. Once approved, workflows run as programmed.

Approval Requirements

Approval requirements are the items that must be satisfied (checked off) before the workflow can be approved. Each approval requirement directly relates to use of a protected resource. You can see the approval requirements for a workflow by selecting the workflow in the Queue View, right-click and select "Approval Review".

The left side lists the approval requirements. There you see the "Status" that describes the current state of the approval of that particular item. The "Type" and "Object Name" describe the particular thing that needs approval. Finally, "Operations" describe the verbs in the ACL the approver be allowed access based on the ACL of the object.

For example, the first row from the image above shows that the approver must have both "Read" and "Execute" access to the user "dave". So, under "Users and Service Accounts", you will find a user "dave". It is the ACL on that user that is tested in this case. The approver must have the ability to read and execute.

Status

The following are the values of "Status".

ApprovedA person has approved this requirement.
Not ApprovedThis requirement is awaiting approval.

Type

The following are the types of approvals.

AssetA particular asset in the Object Browser. By default approval based on asset is turned off. If "approve_assets" is set to "true" in the /opt/situate/situate.properties file on the server, then the ACL on the assets in the object browser will be used to generate an approval requirement for the assets contained within the workflow. This may be useful in companies that have many teams of people, each "owining" their own computers (assets). In this case these additional approval requirements would prevent a team from accessing another team's assets.
GroupA member of the Situate group in "Object Name".
PolicyA user possessing the policy indicated in "Object Name".
UserA person possessing access to the user or service account indicated in "Object Name".
WorkflowA person possessing access to the workflow indicated in "Object Name".

Approvers

The right side of the approval requirements view contains the list of approvers -- the set of all people who approved the workflow and contributed to the satisfaction of at least one approval requirement.

Anyone Can Submit

The approval process allows anyone to submit a workflow even if the submitter lacks permission to access the protected resources the workflow uses.

This allows workflow designers to perform the work of creating a workflow but leaves the approval of that workflow in the hands of someone who must review that work.

Executing the Workflow

Once approved, the ACL on the workflow describes who can execute it. The approval process can therefore be used to allow a lesser privileged user to access protected resources they would otherwise not be able to access, but that access can only be through the approved workflow.

Workload Automation and Orchestration