Hi Community,
Not so much a development question as more of a OOTB workflow question but hoping that someone might have come across this issue before I log it with ServiceNow.
The company I work for is using the Contract module (out of the box, no workflow amendments/additions).
Issue: We have occasions when the ‘State’ and ‘Substate’ fields are going in to ‘Read Only’ mode although the ‘State’ = ‘Draft’ and ‘Substate’ = ‘Approved’. My understanding is that it should NOT go in to ‘Read Only’ mode against ‘State’ = ‘Draft’ (only first when it goes in to ‘Active’, ‘Expired, or ‘Cancelled’.
In other words, in this case sometimes after Contract approval workflow has been ‘Approved’, instead of Contract going to ‘Active’ state it sets the two fields to ‘Read Only’ mode although the ‘State’ = ‘Draft’ and ‘Substate’ = ‘Approved’.
At this point the user and myself cannot move this Contract to 'Active'. I do not mind the ‘read only’ as believe this is the default set in the Dictionary Entry for this field (https://[instance]/sys_dictionary_list.do?sysparm_query=nameSTARTSWITHast_contract%5Eelement%3Dstate) but the state needs to display the correct value after approval (seems as it is here it fails, the state never makes it to active).
Has anyone seen this before, and if so what is the remedy? If no Remedy then do anyone know what system record controls the ‘state’ change action of this field as the clue might be in there as to why it set's it to read only prematurely (and fails to set it as ‘Active’).
Grateful for feedback.
Thank You.
Henrik
A new contract should have State = Draft, Substate = Awaiting Review
Once (UI Action) Submit for Review is clicked, State should not change, Substate = Under Review, and the only contract workflow should start. If new contract, workflow will follow below:
Once approved, the state of the contract is changed to either approved or rejected based on the End Date selected. Substate should be noce.
While the business rule - Manage Contract Lifecycle - is driving the state changes, the BR is getting what data to set from the Condition Check Definitions (module). Out of box choices look like this:
There is also a Scheduled job that runs daily named - Contract: Run Condition Checks - that checks the contract data against this table and moves the State/Substate based on the conditions defined in this table.
So a) confirm your workflow is running, b) confirm the condition checks table is populated correctly.
