- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-25-2017 05:31 AM
I am finding these two fields are editable till end. Ideally post authorized by CAB (mean in Scheduled / Implement / Review state), in case of normal change, these fields shall not be editable. Any reason why these are kept editable? I tested this in Istanbul instance. I can add UI-Policies etc, but want to know the reason behind it.
Thanks.
Solved! Go to Solution.
- Labels:
-
Change Management

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-27-2017 07:15 PM
What we did:
1) created a UI Policy to make Planned Start & Planned End read-only if State is not New.
2) created a UI Action that:
- Returns the state back to New so Planned Dates can be changed. (Happy to provide the full script if you need it)
3) Modified oob Business rule named - SNC Approval - Reset conditions
- Business Rule will reset the workflow
Note: the business rule has lots of comments to explain how it works exactly.
For the Reset Condition we are using: if (current.state.changesTo("-5"))
so reset triggers when State changes back to New
Then we're using Option 2 in the BR:
new WorkflowApprovalUtils().reset(current, comment);
current.approval = 'not requested';
gs.addInfoMessage('Workflow has been reset since Planned Dates have been modified');
This should give you the basics
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2020 11:21 AM
One more thing - does this set it back to Assess?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2020 12:13 PM
Here's the script but two things: 1) Revert to new now comes out of the box, and 2) you still have to play within the rules defined by script includes that handles state changes.
var changeConfirmCancelDialog;
function loadConfirmDialogRewrite() {
var dialogClass = window.GlideModal ? GlideModal : GlideDialogWindow;
changeConfirmCancelDialog = new dialogClass("change_confirm_rewrite", false, 648, 250);
changeConfirmCancelDialog.setTitle(new GwtMessage().getMessage("Rewriting the Change will delete all existing approvals"));
changeConfirmCancelDialog.render();
}
function moveToDraft(notes) {
var ga = new GlideAjax("ChangeRequestStateHandlerAjax");
ga.addParam("sysparm_name", "getStateValue");
ga.addParam("sysparm_state_name", "draft");
ga.getXMLAnswer(function(stateValue) {
g_form.setValue("state", stateValue);
g_form.setValue("comments", notes);
changeConfirmCancelDialog.destroy();
gsftSubmit(null, g_form.getFormElement(), "planned_dates");
});
}
if (typeof window == 'undefined')
setRedirect();
function setRedirect() {
current.update();
action.setRedirectURL(current);
}

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-26-2017 05:23 PM
Because every customer has unique processes, so OOTB should not enforce rules that would not apply to all implementations.
You'll notice that not much is locked down OOTB for that reason.
ServiceNow Nerd
ServiceNow Developer MVP 2020-2022
ServiceNow Community MVP 2019-2022
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-26-2017 10:12 PM
What customers looks from a product is some already inbuilt standard practices. Customization takes a lot of time and cost.
With Regards
Bhupesh Gupta

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-27-2017 07:06 PM
Engage with ServiceNow Partners who can quickly configure your system to align with your processes and ServiceNow best practice
Some will have pre-packaged use cases they can apply instantly to your system.
It really doesn't take that long to setup ACLs and minor configuration to workflow.
ServiceNow Nerd
ServiceNow Developer MVP 2020-2022
ServiceNow Community MVP 2019-2022