This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

How to block ad-hoc change requests?

We don't want our people to use the 'Ad-Hoc' change request item because there are no approval workflows, and therefor no accountability. 

Is there anyway to stop users from creating 'Ad-Hoc' requests and only use the CCIs? 

From a process perspective, we've created a generic "Request for Change" CCI that acts as our catch all. 

Parents
  • As the Product Manager responsible for the implementation of the change CCI, I am very happy to hear that you completely transferred your organization to rely on them.

    Currently there is no way to completely remove the Ad-Hoc option for the account.

    A possible "educational solution" might be to create an automatic rejection (via automation role) on such change requests, while explaining to the user  the right process.

    Hope it helps

    Amir

  • I'm looking at the conditions in Automation Rules, but there doesn't appear to by anything that can target "Ad-Hoc" changes explicitly. Do you have any recommendations on how to select a condition?

  • You are raising a good point that we don't have a specific condition to catch only the ad-hoc changes...you can open an enhancement request about it.

    As a workaround, the only thing that comes into my mind, is to to use State=Open as the condition (which I believe is the default state set when you create a new ad-hoc change), and in all of the CCIs, you add an update record line that will set their initial state to "Open CCI" (as an example).

    You should be able to distinguish between the two origins like that.  I hope this helps.

    Amir

Reply
  • You are raising a good point that we don't have a specific condition to catch only the ad-hoc changes...you can open an enhancement request about it.

    As a workaround, the only thing that comes into my mind, is to to use State=Open as the condition (which I believe is the default state set when you create a new ad-hoc change), and in all of the CCIs, you add an update record line that will set their initial state to "Open CCI" (as an example).

    You should be able to distinguish between the two origins like that.  I hope this helps.

    Amir

Children