Best Practice for Multiple Editors in Adobe Launch

[BarryLennon]

Some Background

My organisation migrated to Adobe Launch from Adobe DTM in 2019.

There are typically 3-4 people working on the same Property at any given time.

In DTM, our "rule" for editing was:  do not edit any Resource (Rule, Data Element, etc.) where "Status" is "Unapproved"

In essence, this enforces the idea that an Approved change to a Resource can only come from a single Editor at a time.

Adobe Launch

When we started working with Adobe Launch, we assumed there was no longer any need for "manual" rules like our DTM example, because the separate DEVELOPMENT environments would keep changes to a single Resource on different "branches" (to borrow a term from versioning systems).

This assumption was proven to be wrong (everyone is always editing the same instance of each Resource, albeit creating new versions as they go), and the need for a manually-enforced approach is still there.

The Problem

In Adobe Launch, the unanticipated problem we encounter (with multiple Editors in a single Property) is this:  we cannot find an indicator that a Resource is in some "edited" state.

Bear with me while I describe a scenario that leads to a Resource being in what I've dubbed an "edited" state and how this has dangerous consequences:

1. A Property has a single Rule named "All Page Rule"
2. A Property has a single Published Library containing Rule "All Page Rule (version 1)"
3. Editor AAA creates a new Development Library named "Library 111" and sets her working library to "Library 111"
4. Editor AAA modifies Rule "All Page Rule", thereby creating a new version ("All Page Rule (version 2)")
5. Editor BBB creates a new Development Library named "Library 222" and sets his working library to "Library 222"
   • NOTE: If, at this precise stage, Editor BBB publishes "Library 222", it will include "All Page Rule (version 1)", i.e. it will not take into account the change made by Editor AAA; for the purposes of this post, we will assume Editor BBB does not do this
6. Editor BBB searches for Rule "All Page Rule" and makes a modification; Editor BBB saves his changes and builds his library
   • This is the point at which the multi-Editor scenario falls down in our experience:  although Editor BBB created his library with Rule "All Page Rule (version 1)", when he opted to modify Rule "All Page Rule", Adobe Launch presented him with Rule "All Page Rule (version 2)", which is the non-Published edited version created by Editor AAA's actions
     • The result of this is that Editor BBB's library ("Library 222") now contains Rule "All Page Rule (version 3)", which incorporates Editor AAA's non-Published changes as well as Editor BBB's

We've been dancing around this limitation for a while now, but when we discovered "unapproved" code had made it into our Production deployment, it was clearly time to look for a better approach.

The Question

Really, I have two questions:

1. Is everything I described under "The Problem" correct?
   • I'm fairly certain it is, since I did some additional verification as I wrote this
2. What practices are you following in a multi-Editor Launch property to accommodate this limitation?

[franzli · Accepted solution]

This is an interesting situation and also very similar to me. I believe this is somewhat rare in most cases just because there usually is just one person working on a property. But in our unique case, a blessing and a curse to have many implementation team members, the best practice (which we also do) is to have all your code hosted in a repository like github.

• If we are working on a significant portion of the implementation, we duplicate the property and spin-off a new property. 
• We use DTM switch or Adobe Debugger to switch and test.
• Once we have the code and confirmed it working, we publish and pull it into the master code repository in git. 
• Once merged, we then have "authority" to put that code into the production property. 
• In most cases, data elements and rule action custom code is quite simple so it's easy to see but when we encounter a long piece of code, we do a simple difference check between what's on launch and what's on git and use git as our source of truth.

The process took time to figure out but we found that worked and kept our code clean and the process is now second nature to us.

[Haran_Huang]

Everyone operates on the same instance. Although there are different environments, the environment is just a demo site, which is essentially a one-to-many relationship, one instance, multiple demos, so the settings are still on one instance.

Therefore, when generating a library in the development environment, you need to select your own set Resource.

[jantzen_b]

Do any of the answers below answer your initial question? If so, can you select one of them as the correct answer? If none of the answers already provided answer your question, can you provide additional information to better help the community solve your question?