State on RITM Set By Workflow Being Overwritten

[jmiskey]

So, we currently have a Catalog Item that has a workflow attached to it.  The workflow runs off of the sc_req_item table and has some Approvals.  I have it set so that if an Approval is rejected, the workflow goes to a "Set Values" action that sets the "State" of the RITM to "Closed Rejected", and then sends out a Notification and goes to the End.

Whenever I test one, and Reject an Approval, it looks like it is going down the correct Workflow path, but for some reason my State appears to be overwritten, as it is always set to "Closed Complete".  And it isn't just this one workflow, but this appears to be happening to all of our workflows that are trying to set the State to "Closed Rejected". 

Here is what my action looks like. 

I have tried it with various different values for Stage ("Request Cancelled" or "Completed"), but it does not appear to make any difference.  

We checked the Business Rules, and I could not find any which appear to be interfering with this.  Is there anything else which could be causing this to happen?  How can I find out what is causing this?

Thanks

[jmiskey]

Yes, that is what I originally suspected, which brings me back to the question I posted in my first post:

We checked the Business Rules, and I could not find any which appear to be interfering with this.  Is there anything else which could be causing this to happen?  How can I find out what is causing this?

[Steven Parker]

ServiceNow HI may need to help on this.

What's odd is it doesn't even recognize your "Set Value" activity even if you put a Timer activity behind it...so why is it skipping or ignoring that "Set Value" activity is the question I would ask.  You could also ask them what is setting the requested item state to Closed Complete as well...I am sure there is a business rule or something doing it.

[jmiskey · Accepted solution]

It turns out that there was another Business Rule affecting this.  It just wasn't where we were looking.  It was a Business Rule on the Task table, and it wasn't one that we created (but by the ServiceNow team that got us up and running on ServiceNow a few years ago).

Also, in case others come across problems like this in the future, here is another article which may be helpful.  https://community.servicenow.com/community?id=community_blog&sys_id=264d6229dbd0dbc01dcaf3231f96195a