[Playbooks] Update set of playbooks contains multiple updates by system in different scope

[akym]

I have multiple system updates from different scopes in my US containing playbooks development, if you had such an issue, how did you handle it?

[GlideFather]

ahoj @akym,

and what do you want to do - deploy or remove these?

If you have a record from other scope in your update set, then switch to that scope and remove that association from Parent field. Or you can do any desired changes to that.

Let me know if that answers your question or if I got it wrong and you asked a different thing.... 

PS: do you still drink bamboocha or just ocassionally? :))

Kamil

[akym]

Heyyy!
I want to deploy them, but there are bunch of updates that have application scope empty, and relatively big number of different scopes involved, so I would like to avoid creating US for each scope and batch them together
I was wondering if we even need those updates, but it is a first time deploying playbooks, so needed some guidance
P.S. Time to time :)))

[GlideFather]

@akym empty application scope seems like some glitch.. there should always be some 😮 

If you don't know you can create a case from the support portal (if you have that access)

[Tanushree Maiti]

Hi @akym 

To resolve mixed-scope update sets, avoid reassigning updates from one application scope to another within the same update set.

Instead, identify the updates belonging to each scope and separate them into individual update sets that correspond to their respective application scopes.

If the parent update set contains updates from multiple scopes, create child update sets for each scope and organize them using Hierarchy Update Sets. This approach maintains scope integrity, simplifies deployment, and allows multiple related update sets to be promoted together as a single logical package.

I can recall in one of client project when we tried to move a update set with different scopes' updates   captured in a single update set ,  It was throwing error in target instance.

Better capture it with same story's different update set .

 That time we  backed out from target instance-> again recapture from Dev instance-> then moved to next instance.