catalog item

[Rishabh_N]

Hi everyone,

I have a catalog item for group retirement. Before retiring a group, I need to check its dependencies.
I created a Script Include to check dependencies (like Business Rules, ACLs, UI Actions, Client Scripts, etc.) and used it in a workflow Run Script activity  it works fine, but it’s hardcoded and limited.

My question is if a group has a lot of dependencies (some that we don’t even know), how can we identify them dynamically? Since we can’t write individual methods for each dependency in the Script Include, what’s the best approach or best practice in real-time projects?

[Ajay_Chavan · Accepted solution]

@Rishabh_N - did you check?

[RaghavSh]

So it has to be checked individually and it gets complex with flows being used in workflow/ flow designer.

But refer https://www.servicenow.com/community/developer-articles/checking-group-dependency-before-deactivatin...  

this article is quite detailed and will be helpful.

[RaghavSh]

@Rishabh_N Did you check this?

[Rishabh_N]

Thanks for sharing this @RaghavSh  and @Ajay_Chavan . I have implemented something similar I wrote a Script Include that checks for common dependencies (Business Rules, Client script, ACLs, UI Actions, Notifications, etc.) and I call it in the Workflow. If dependencies are found, the workflow creates a Catalog Task for an admin to review and handle any unknown dependencies before retiring the group. I didn’t create a custom table for tracking like in this artical. So from your experience, is this hybrid approach (automation for known dependencies + manual review for unknowns) considered a correct practice in real-time?

Your reply would be really helpful for me

[RaghavSh · Accepted solution]

@Rishabh_N Custom table is not necessary, what is important here is that someone take care of dependencies before deleting/deactivating the group.

What you did is absolutely fine and will work in real time as well.

One more thing you need to add in your catalog task description or maybe variable is that anyone who is working on the task should reassign the task based record( inc/prb/change/sc_task) or any other module you are using to some active group or get these records closed before deactivating. This step can also be automated in your workflow with simple glide on task table and querying open records with existing group and replacing that, but its totally upto your wish , how you want to implement this.