Best practice for customizations? (Scopes, Cloning and Update Sets).

[Community Alums]

I am about to Implement the HRSD Integration with SuccessFactors.

It will require a significant amount of customization to add new Fields, new services for importing additional tables, new flows for Full and delta loads and new flow actions which can use a different alias for different environments (dev, test etc). .  I expect I will be making modifications in maybe 5 or 6 different Applications scopes.  I have three interrelated questions about best practice.  What is your experience with the following?

A.  What option do I use for managing scopes:

1. Do I create a new custom Scope and put all my customization is the new scope?   What about RCAs?
2. Do I use the global Scope only?
3. Do I put my customizations in the appropriate 5-6 scopes?  (harder to manage update sets)

B.  To clone or not to clone?

1. Do I clone items (such as flows)?
2. Or edit existing items?

C. Managing Update Sets

1. Do I use Merge update Sets?
2. Create use Batch Update Sets?
3. Do I created Update Set versions and then use the "Copy Update Set Utility" when creating a new version.

Possible Solution

I did find this post.
https://www.servicenow.com/community/now-platform-blog/best-practices-for-using-the-flow-designer/ba...
Which suggest a Best practice is:  A.1 (custom Scope);   B.1 (clone so you get updates); and C.3.

Copy Update Set Utility:  see:  https://developer.servicenow.com/connect.do#!/share/contents/3673648_copy_update_set?v=1.5&t=PRODUCT...

[JulianLemcke]

Good morning,

I would personally go with:

• A1: It is much easier distinguishable what is "custom" and what is "OOTB". Furthermore, you can also deploy in the future (if your setup is mature enough) the entire application. I do have currently the unpleasant situation that everything in the "HRSD World" has been done in the OOTB scopes which makes it way harder to distinguish
• If you build from the ground up, I would say B1. However, in someways it is better to overwritte OOTB stuff (Script Includes, BRs etc.) so that you do have the versioning always at hand
• I would go with C2 & C3. Create a large "Parent Update Set" and then child "version sets". You can also put the Parent in Global and then all child update sets in the respective scope.

Cheers,

Julian

[Community Alums]

Thanks for your replies.  Julian and Susan.  Much appreciated. 

A.  In terms of Scope, In the past I have done what Susan suggested.  Howevever, as you mentioened it is then hard to understand what is custom.  I am also working with a Customer who started over with ServiceNow from scratch - in order to reduce and mange customisation better.  So I like the idea of using a custom scope for the reason that you mentioned Julian - although I have never done this for real in the past.  

B.  I hear what you are saying about overwritting custom stuff in order to have the versioning record present - but this would prevent me from using only one custom scope, so I am leaning towards cloning as Susan Suggested.   

C.  Update Sets.  If I am using just oner Scope, then I have one update set.  So no Batch Required.  So I can use option C.3.

So overall, I think I am leaning towards:  A:  Custom Scope, B: Cloning, C:  3. Just one update set - with versions. 

[JulianLemcke]

Glad that you got some good help here!

[Susan Britt]

A) I would put the customizations in the appropriate application scopes

B) Always clone the OOB flows, subflows, actions, script includes, etc that you may need to customize for your integration.  This will allow the OOB versions to still be updated with new releases, give you something to look back on if you mess up with customizations or encounter issues later on.

C) Create your update sets in the appropriate application scopes and batch them

• When working on development work that crosses application scopes, I will create all the update sets in their scopes in the beginning (e.g., HRSD-SuccessFactors Integration-Global, HRSD-SuccessFactors Integration-HR Integrations).  As you create them, go ahead and say make it your current update set.  Then as you are working and switching application scopes, the right update set is used.
• Always validate all the update sets before completing the parent batch update set 
  • Ensure the application scope of the change/update matches the application scope of the update set (move if it does not)
  • Ensure only changes you want captured/promoted are included (i.e., do you have a "Test" flow that could be moved out to a default update set)
  • Check sys_update_xml table to make sure all of your changes are in the update sets and not in default