The Brief Change Request workflow is used to execute simple changes to your plant within your company or execute and collaborate on large projects with contractors using SDx Projects.
The steps that make up the workflow are described in the following table.
If you choose to edit the workflow, do not remove any steps marked as mandatory.
For information on how to upgrade a workflow template, and the changes that have
been made in various updates, see Upgrade the change request workflow templates.
The following diagram shows all of the steps in the Brief Change Request workflow.
|
Step name |
Description |
Mandatory? |
Comments |
|---|---|---|---|
|
SOPSBranchBasedOnSaveAsDraftForBriefChangeRequest |
Evaluates whether the user selected Prepare Change or Finish on the Create Change Request page. The next step is Prepare change request if Prepare Change is used, or Set change request status to in-progress if Finish is used. |
No |
|
|
Prepare change request |
Allows the creator of the change request to relate documents and tags to the change request, create markups, and check for impacts and conflicts. If this step is removed, change requests cannot have additional documents or tags related to them. This step may not be required if the change request is created directly from a document or tag. The next step is Set change request status to in-progress (if Complete is used). |
No |
|
|
Set change request status to in-progress |
Changes the status of the change request to In Progress. If this step is removed, the change request status will not be modified. The next step is Evaluate change and approve. |
No |
|
|
Evaluate change and approve |
Allows a user with the MoC Owner role to review the change request for feasibility and to identify any potential conflicts. If accepted, the next step is Generate merged PDF rendition. If rejected, or if rework is required, the next step is Reject Evaluate Feasibility. |
No |
|
|
Generate merged PDF rendition |
Creates a single PDF rendition of the change request, including markups and attached files. This PDF rendition remains available for the change request even after it is closed. If the PDF is successfully created, the next step is Set change request status to approved. If the PDF generation failed, the next step is Correct Failure Generate merged PDF rendition. |
No |
|
|
Correct Failure Generate merged PDF rendition |
Allows a user with the MoC Owner role to either correct the issues that caused the PDF generation to fail or reject the change request. If the user resolves the issue, the next step is Generate merged PDF rendition. If the user decides to reject the change request, the next step is Set change request status to rejected. |
No |
|
|
Set change request status to approved |
Changes the status of the change request to Approved. If this step is removed, the change request status will not be modified. The next step is Check for the config. |
No |
|
|
Check for the config |
Checks whether the change request has been assigned to a project. If the change request has been assigned to a project, the next step is Claim to project. Otherwise, it is Co-ordinate change implementation. |
No |
|
|
Claim to project |
Claims the change request to the specified project, if applicable. This step can be bypassed if there's no project assigned to the change request. If the change request is successfully claimed to the project, the next step is Co-ordinate change implementation. If it fails to be claimed, the next step is Correct Failure. |
No |
|
|
Correct Failure |
Allows a user with the MoC Owner role to either correct the issues that caused the failure or reject the change request. If the user resolves the issue, the next step is Claim to project. If the user decides to reject the change request, the next step is Set change request status to rejected. |
No |
|
|
Co-ordinate change implementation |
Allows a user with the MoC Owner role to execute the change request using internal change actions. If the change request involves external contractors, SDx Projects can be used, if purchased. The next step is Review proposed solutions. |
Yes |
This step should not be removed from the workflow as it is where the changes requested are actually completed. |
|
Review proposed solutions |
Allows a user with the MoC Approver role to review the changes proposed for this change request. The next step is either Is action workflow in progress if the user approves the change request, or Reject Review Proposed Solution if they reject it or send it for further work. |
Yes |
This step should not be removed from the workflow as it ensures the correct changes are implemented. |
|
Is action workflow in progress |
Checks to see if any actions related to this workflow are still in progress. The workflow will only move to the next step if there are no actions in progress on an object related to the change request. The next step is Is merge required Implemented. |
No |
|
|
Is merge required Implemented |
Checks to see if a merge is required. If a merge is required, the next step is Are change items mergeable before completion. If no merge is required, the next step is Is merge required Approved. |
No |
|
|
Are change items mergeable before completion |
Checks whether there are any conflicts at the project level. If there are no conflicts, the next step is Is merge required Approved. Otherwise, it is Resolve conflicts. |
No |
|
|
Resolve conflicts |
Allows a user with the Discipline Lead role to view and resolve any conflicts that exist in the project scope. The next step is Is merge required Approved. |
Yes |
This step should not be removed from the workflow as you cannot merge objects to the plant level if there are conflicts. |
|
Is merge required Approved |
Checks again to see if a merge is required. If a merge is required, the next step is Are change items mergeable before merge. If no merge is required, the next step is Generate final merged PDF rendition. |
No |
|
|
Are change items mergeable before merge |
Checks whether there are any conflicts at the project level. If there are no conflicts, the next step is Merge documents and tags. Otherwise, it is Resolve conflicts for merge. |
No |
|
|
Resolve conflicts for merge |
Allows a user with the Discipline Lead role to view and resolve any conflicts that exist before merging the change request to the plant scope. The next step is Are change items mergeable final validation. |
No |
|
|
Are change items mergeable final validation |
Checks again whether there are any conflicts at the project level. If there are no conflicts, the next step is Merge documents and tags. Otherwise, it is Resolve conflicts for merge. |
No |
|
|
Merge documents and tags |
Merges documents and tags that are related to the change request to the plant configuration. The next step is Merge change management. |
Yes |
If you remove this step from the workflow, the updated documents and tags will not be available at the plant level. |
|
Merge change management |
Merges the change request to the plant configuration. The next step is Generate final merged PDF rendition. |
Yes |
If you remove this step from the workflow, the change request will not be available at the plant level. |
|
Generate final merged PDF rendition |
Creates a single PDF rendition of the change request, including markups and attached files. This PDF rendition remains available for the change request even after it is closed. If the PDF is successfully created, the next step is Set change request status to completed. If the PDF generation failed, the next step is Final Correct Failure Generate merged PDF rendition. |
No |
|
|
Final Correct Failure Generate merged PDF rendition |
Allows a user with the MoC Owner role to either correct the issues that caused the PDF generation to fail or reject the change request. If the user resolves the issue, the next step is Generate final merged PDF rendition. If the user decides to reject the change request, the next step is Set change request status to rejected. |
No |
|
|
Set change request status to completed |
Changes the status of the change request to Completed. If this step is removed, the change request status will not be modified. The next step is Clear change request. |
No |
|
|
Set change request status to rejected |
Changes the status of the change request to Rejected. The next step is Clear change request. |
No |
|
|
Clear change request |
Deletes the markups related to the change request. The next step is Completion notice. |
No |
|
|
Completion notice |
Allows the creator of the change request to complete it. This is an acknowledgment step. This is the last step in the workflow. |
No |
|
|
Reject Evaluate Feasibility |
Identifies whether the change request was sent for rework or was rejected at the Evaluate change and approve step. If it was sent for rework, the next step is Revise Evaluate Feasibility. If it was rejected, the next step is Set change request status to rejected. |
No |
|
|
Reject Review Proposed Solution |
Identifies whether the change request was sent for rework or was rejected at the Review proposed solutions step. If it was sent for rework, the next step is Revise Proposed Change. If it was rejected, the next step is Set change request status to rejected. |
No |
|
|
Revise Evaluate Feasibility |
Creates a new revision of the change request. The next step is Prepare change request. |
No |
|
|
Revise Proposed Change |
Creates a new revision of the change request. The next step is Co-ordinate change implementation. |
No |