Org models are the central pillar of the Elements platform. Most use cases for using Elements rely, at least partly, on using Org Models to some extent. Therefore it is crucial for you to understand exactly what they are, how they work, and how you should go about connecting your Orgs to the Elements Space.
LO1-1 Understanding the concept of implementation, and when I would need more than one implementation
Proposed? : Understand what an Org model is, and allows you to do
LO1-2 Understanding what connecting Orgs to the same implementation does for me
LO1-3 Being able to connect multiple Orgs to the same implementation
LO1-4 Being able to decide how many implementations I need for a single Space
An Org Model is a collection of your Org’s metadata represented as ‘nodes’ within Elements. Every day we sync and update the Org Model to make sure it represents the most up-to-date view of your Org’s configuration and architecture.
By default, the Org Model displays the synced metadata in ‘metadata dictionary’ view. It is a hierarchical list of metadata grouped by type (e.g. flows, apex classes, objects, fields etc.). By opening each item in the list (click on the grey arrow) you can see individual metadata belonging to that type (also organised alphabetically).
Org Models allow you to document individual metadata, run dependency analysis, check usage, assess items for clean-up or removal, link planned changes and many more. All of the use-cases will be covered in other academy courses.
Every Org Model has its own analytics report that allows you to see aggregate stats about your Org’s health and changes over time. You can also generate reports on the scope of metadata by any chosen attribute to perform further analysis and identify the scope of metadata for a change.
In Elements, we see a single Salesforce Production Org and its associated Sandboxes as a single Salesforce implementation. The ‘implementation’ in the platform is therefore a grouping for the Org Models.
The implementation is fundamental to successful utilisation of Elements for Org Management. All Org Models that belong to the same implementation share documentation, links and chat history for nodes with the same Salesforce API name.
This means that a user story, a URL link, a rich text note, a tag, or feedback left by the end user on the ‘Account’ object in the Production Org Model is instantly visible in any Sandbox Org Model in the same implementation, as seen below.
This architecture allows for cross-environment communication and avoidance of conflict between planned changes. As soon as the newly created/refreshed Sandbox is connected to Elements (and the Org Model is produced), documentation on how the configuration works, who is working on it, why and where, is instantly visible to any user working in that new Sandbox.
The implementation is enabled for a Space through a separate connection license. If you want more than 1 implementation, you would need to purchase additional connection licenses for your Space.
Now, to address a few common questions…
Ideally, you should connect and sync your Production Org and every Sandbox Org to the same implementation in your Space. You should connect and sync every new Sandbox you create to your implementation, and you should delete Org Models for Sandboxes you have deleted. In short, Org Models grouped in your Elements implementation should represent your full, current Org environment landscape.
Again, this ensures that you have full and instant visibility of all changes happening in your environments. You can successfully detect, manage and resolve conflicts between different changes before any work is started, and you can ensure any documentation you produce is live because it is available in context and on-demand on every metadata, in every environment.
Some organisations have multiple production Orgs for different business units. In that case, it is advisable to purchase multiple connection licenses and set up separate implementations for each Production Org and associated Sandbox Orgs.
However, this might not always be the best solution.
If the same team of admins, business analysts and developers is responsible for all the Production Orgs, and therefore they utilize the same workflow and methodologies when changing the configuration, it is indeed best to have multiple implementations in the same Space.
However, if there are different teams responsible for different Orgs, with their own unique ways of working, it might be more effective to have a separate Space for each team with just one implementation with each one of those Spaces.
Have a look at the example below,
Previously we looked at a company ‘Zenalpha’ that had 2 core Spaces: ‘Zenalpha Operations’ and ‘Zenalpha Production’.
‘Zenalpha Operations’ has 1 implementation with a Production Org Model and multiple Sandbox Org Models. The Production Org Model represents the Org used by Zenalpha’s sales, marketing, customer success and other teams. It is the Org on which the entire business is run. The Space is owned by the Platform Owner for the Zenalpha Org and it is used to manage changes by the business analysts and admins.
‘Zenalpha Production’ has 3 implementations for 3 different sets of Developer Orgs. It is owned by the Product Manager and used by the development team to build and publish the company’s Managed Packages – the products they sell to their customers.
Because the development process and required workflows are different from how the internal admin team uses, they set up this separate Space to conduct their own work.
Next, you will take a short, theory and practical quiz. Select it from the menu below.
This quiz will help you to recognise the skills and knowledge you have gained, and identify any areas you still need to explore and learn.
Remember, you can revisit these pages, or ask us for help if you get stuck. Once you pass the quiz, click “Mark as completed” to complete the course.