Change Requests not moving to Scheduled state after approval in Authorized state

ramirch
Tera Contributor

Hi there.

We cloned our TEST instance with PROD, then upgraded TEST to San Diego. 
When we open existing tickets cloned from PROD, and approve a Change Request in 'Authorize' state the CHG does not move to 'Scheduled' state even if the CHG was successfully approved.

Is this an expected behavior when testing Change tickets cloned over from PROD?

Thank you.

6 REPLIES 6

Weird
Mega Sage

Workflows are not cloned so you're lacking the logic for transition in your test environment.
You could try manually moving the workflow from prod to test, but I'd just create a new change in test instead.


Edit:
If you really want to clone them, check the exclude tables in the navigation (System Clone -> Clone Definition -> Exclude Tables. If you remove the records starting with "wf" you would be able to include them in the clone, but 99.9% of them are useless for testing, so I wouldn't clone them.

ramirch
Tera Contributor

Joni, this was what I initially thought. However, existing tickets in Assess state can be moved to the Authorize state after approval. This is not the case for existing tickets in Authorize state.

I also checked the Workflow for the Change Requests that did not move to Scheduled, and it is stuck at the Assess state even though when it was cloned, the state was Authorize.

Do you have an idea why this is?

Thanks.

Mahendra RC
Mega Sage

Hello Chidmark,

Could you please check if any of the table related to Workflow context data is excluded from clone. By default the workflow context data tables are excluded from being cloned. So there may be the case that some tables related to Workflow context are removed from excluded tables but still there may be some table which are still excluded. Please check for tables starting with prefix of wf_ in excluded table on your Production instance for clone that took place.

Note: Excluded workflow context data includes records stored in the wf_context table, and in related tables with names starting with a prefix of wf_. This also includes the workflow scheduler table. This prevents occurrence of workflow timer syncing issues that might take place due to the length of the cloning process if workflow contexts were included.

Please if KB0724419 helps you to understand your issue.

Please mark my respsone as helpful/correct, if it answer your question.

Thanks

Hello Chidmark,

Just wanted to check with you, if the my above response answered your question. If yes, then please do close this thread/question by marking the appropriate response as correct.

If you still need any further help or guidance on this then please update those on this question.

Thanks