The Temporary change request workflow is used to request and document temporary changes. It also supports the process of reverting a temporary change back to its original state or extending it until a later date using the Temporary change request review workflow. For information on the Temporary change request review workflow, see Temporary change request review workflow.
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.
|
Step name |
Description |
Mandatory? |
Comments |
|---|---|---|---|
|
SOPSBranchBasedOnSaveAsDraftForTempChangeRequest |
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 feasibility. |
No |
|
|
Evaluate feasibility |
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 Rendition. If rejected, or if rework is required, the next step is Reject Evaluate feasibility. |
No |
|
|
Generate Merged 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 Final Approval. If the PDF generation failed, the next step is Correct Generate Merged Rendition Failure. |
No |
|
|
Correct Generate Merged Rendition Failure |
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 Rendition. If the user decides to reject the change request, the next step is Set change request status to rejected. |
No |
|
|
Final Approval |
Allows a user with the MoC Approver role to review the changes proposed for this change request. The next step is either Set change request status to approved if the user approves the change request, or Reject Final Approval 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. |
|
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 Co-ordinate change implementation. |
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 Review construction and accept completion. |
No |
|
|
Review construction and accept completion |
Allows a user with the MoC Owner role to review the changes carried out for this change request. The next step is Generate Final Merged Rendition. |
No |
|
|
Generate Final Merged 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 Closure approval. If the PDF generation failed, the next step is Correct Generate Final Merged Rendition Failure. |
No |
|
|
Correct Generate Final Merged Rendition Failure |
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 Rendition. If the user decides to reject the change request, the next step is Set change request status to rejected. |
No |
|
|
Closure approval |
Allows a user with the MoC Approver role to review the changes and approve the change request closure. The next step is Set change request status to completed. |
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 Create scheduler task. |
No |
|
|
Set change request status to rejected |
Changes the status of the change request to Rejected. The next step is Completion notice. |
No |
|
|
Create scheduler task |
Schedules a task to start a Temporary change request review workflow a defined number of days before the expiration date is reached.
If the task is successfully created, the next step is Completion notice. Otherwise, it is Correct Failure. |
Yes |
If this step is removed, the task will not be created and the Temporary change request review workflow will not be automatically started. |
|
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 Create scheduler task. If the user decides to reject 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 feasibility step. If it was sent for rework, the next step is Revise Change at Evaluation. If it was rejected, the next step is Set change request status to rejected. |
No |
|
|
Reject Final Approval |
Identifies whether the change request was sent for rework or was rejected at the Final Approval step. If it was sent for rework, the next step is Revise Change at Approval. 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 Change at Evaluation |
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 |
|
|
Revise Change at Approval |
Creates a new revision of the change request. The next step is Evaluate feasibility. |
No |