Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Valid to date issue

Dhruv Gupta1
Kilo Sage
Kilo Sage

Hi team,

Consider a scenario where someone has raised a policy exception with all valid values and it has been sent for approval and its waiting for the approval and in between the valid to field expires. Then if someone approves a policy exception will the policy exception will move forward or not. 

I tried but its keep on giving the valid to should be in future kind of error and we can't proceed further. Here the user has raised the exception and its approved but due to valid to field getting expired before exception getting approved its stuck.... and state is not getting changed to approved so that workflow could trigger. Is it a feature or a bug!!

 

Regards

Dhruv 

1 ACCEPTED SOLUTION

Phil Swann
Tera Guru
Tera Guru

@Dhruv Gupta I know we spoke on this briefly. 

 

It seems a question of very short timeframes on a PER. If that is the case, I think you need to look more at how you can support the behaviours not bypass the process. Are the approvers having trouble? Are the requesters requesting things too late, or with too little notice? 

 

In change management, the concept of 'retrospective change' exists. In PER , is an approval received for something in the past not a similar thing? A record of something. 

PER was built to help organisations provide temporary relief for any control(s). This means in material terms that those controls will be marked compliant/exempt and attestation will be bypassed. Once closed, the control will revert back and if the issue is still open, will be non-compliant again. If it was an attestation issue and you re-attest (automatically) and the issue is still open, the successful attestation will set the control back to compliant and close the issue. 

 

Trying to alter this approval and overall behaviour is dangerous. PER has just had a really good lick of paint in v10.1 and making changes to any core flows will certainly increase complexity and risk in future upgrades.

 

Happy to discuss more, hope this helps and thanks for reaching out! 

View solution in original post

8 REPLIES 8

Dhruv Gupta1
Kilo Sage
Kilo Sage

Hi @Phil Swann need your help !!

Hi Dhruv,


This was the issue which we also had. We did some modification and bypassed the check if it is waiting for approval state.

 

Check UI Script which handles this.


Thanks,
Ashutosh

Phil Swann
Tera Guru
Tera Guru

@Dhruv Gupta I know we spoke on this briefly. 

 

It seems a question of very short timeframes on a PER. If that is the case, I think you need to look more at how you can support the behaviours not bypass the process. Are the approvers having trouble? Are the requesters requesting things too late, or with too little notice? 

 

In change management, the concept of 'retrospective change' exists. In PER , is an approval received for something in the past not a similar thing? A record of something. 

PER was built to help organisations provide temporary relief for any control(s). This means in material terms that those controls will be marked compliant/exempt and attestation will be bypassed. Once closed, the control will revert back and if the issue is still open, will be non-compliant again. If it was an attestation issue and you re-attest (automatically) and the issue is still open, the successful attestation will set the control back to compliant and close the issue. 

 

Trying to alter this approval and overall behaviour is dangerous. PER has just had a really good lick of paint in v10.1 and making changes to any core flows will certainly increase complexity and risk in future upgrades.

 

Happy to discuss more, hope this helps and thanks for reaching out! 

Sorry was offtrack so could not mark it as answer. So finally we have convinced client to go with OOB and to be on safer side have remove the functionality to allow user to choose time like only dates