We have a small team with multiple people creating, editing, adjusting scenarios etc. This ends up leading to a lot of back and forth to figure out what someone else changed within a scenario, and why.
Curious how different people approach this?
Hi @Nelson_Keating thanks a lot for raising this great question here in the community!
I’m tagging a couple of Make power users who may have interesting experience to share
@alex.newpath @Bjorn.drivn @Richard_Johannes @SebastianMertens
Hi @Nelson_Keating,
that’s indeed a great question and I’m sure people & teams handle it differently.
Version history, seeing what was changed and why, is something we also don’t really do in Make but it would be really great! 
Our general approach:
We usually try to have mostly one person who is mainly working in a scenario.
If it’s an incoming webhook and 10 different things should happen, we try to spread it into multiple sub-scenarios so a mistake in a sub-scenario does not stop everything else.
We also try to name the modules & filters as good as possible so you get a good grasp on what’s going on immediately. Also when working with GoogleSheets we try to put the link to the sheet in the notes of a module so you can easily jump into it.
Would be interested to hear how you approach this @Nelson_Keating ! 
Best,
Richard
@Michaela thx for tagging!
We are using Github. Client has a repo, scenario blueprints are uploaded as a json file {team_id}_{scenario_id}.json. Every significant update is uploaded and has a corresponding Loom recorded to describe the change in addition to the commit message.
The details of the change (name of updater, commit message, Loom url) get added to the commit details, corresponding task in Clickup and our scenario database in Airtable (this forms part of our official documentation for clients).
We of course built all of the above functionality in Make.
1 Like