Technical Articles
Best Practices for Software Collection Handling in SAP Marketing Cloud
This blog post gives an overview on best practices how to handle software collection in SAP Marketing Cloud. As a prerequisite you should know that a software collection is a container for extensibility items.
Clean Desk Strategy
- Create software collections based on topics and keep a stable connection between the extensibility artefacts belonging to that topic and the software collection.
- Try to avoid move and merge of software collections.
- Do not leave the software collection open for long time, but transport as soon as you have tested your enhancements.
- Try to import all released software collections before a release upgrade. This allows hotfix exports in case of issues. Otherwise in case of issues the whole software collection needs to be imported at an unforeseen time.
Closed Topics and Deprecated Content Handling
- Objects, that should not be changed any longer, should be added to an own software collection and this collection should be locked for changes.
- Deprecated content should be added to an own software collection and this collection should be locked for changes and export.
Good tips, thanks Eileen!
When I did my first Marketing cloud project, about 3 year ago, after having worked with the onpremise version, these Software Collections were very confusing to me.
In onpremise, every change you make has to be saved in a transport request. Once the transport request is released and transported, if you change the same object again, this is a new transport request.
So, in this logic, I made a software collection for our first go-live. Transported that one. Then started a new software collection for the changes of the first batch of adaptations and roll-outs. But then I learned that was a mistake 😀 Because the changes made to objects that were already part of the first go live, remained in the first software collection. So I had to transport that one too. But it took a while to realise that ':D
I also find that it's not easy to keep separate collections for separate topics. Especially custom fields and segmentation have many dependencies to one another, so even when certain fields and segmentation profiles are for a different use case/theme, they need to be in the same collection due to dependencies.
The last two tips will be things that I'll start using from now on! I have some objects that are only meant for the test environment and should not be transported. Which now are just not in any collection. But putting them in a locked collection seems like a good plan. Thanks!
Kr
Joyca
Great blog! Thank you
Hey Eileen,
I would agree with Joyca, especially the last tip concerning handling of deprecated content using an own locked collection seems a good idea!
Thank you! 🙂