Monitor Changes to a Production Org (A112)

Monitor Changes to a Production Org

Your Production Org may be changing constantly or only a few times a year. In either case, the platform owner, the delivery manager and even all members of the development team should be aware of how the production environment is changing.

Click to open Learning Objectives

LO1-1 Describe why monitoring of the production org changes is important, and why the entire team should be part of it

LO1-2 Understand how to customize who gets the “Post-Synch” email alerts

LO1-3 Understand how to report on changes in the Production Org

LO1-4 Know where, and able to, to find “change log history” for individual metadata items

Knowing how the production environment is changing allows you to identify the root cause of unexpected bugs much faster, and identify potential conflicts.

Post-Sync email and Slack alerts

Any user who is given access to the Org Model can be granted access to the post-sync email alerts. You can also set up a Slack channel dedicated to Production Org changes and send the post-sync alerts to the channel instead. This would allow your team to collaborate and discuss any changes much more effectively.

The following support article describes in detail how to generate report logs,

Manage who gets daily sync updates – Support Article

You can choose which users receive the daily, post-sync email update about all the changes in your Org. You can use that to make sure your team and all relevant stakeholders are never caught off guard by some changes. Furthermore, you can also set up a Slack channel to receive those updates instead.

In order to set a user as a recipient of the change log summary email for an Org model, you first need to grant them individual access to an Org model. Then, in the share tab in the right panel for the selected Org model, find the user and simply tick ‘Receive update on changes‘. Only users with Org model manager permission can change this setting.

Setting up a Slack channel to receive updates

You can also specify a single Slack channel that will be receiving the daily sync updates.

In the same “Share” tab of the right panel, follow the instructions in the animation below.

 

The subsequent update in slack will look as follows;

Org Changes and Governance

First reason why key decision makers (the platform owner and/or delivery manager) should be aware of any changes to the Production Org has to do with governance. Some changes can be:

  • Unexpected (and unnecessary)
  • Done by people who shouldn’t be changing that metadata
  • Deployed too early / at a wrong time

By monitoring how the Org environment is changing you can monitor and enforce your governance rules and spot issues much earlier.

You can start your journey designing your Org’s governance rules by starting the Org Governance foundations course after you complete this course. 

Click to reveal course link

Org Governance – Stakeholders , opens in new window.

Illustrative example:

Click to open illustrative example

Let’s imagine a junior admin (Sally) was tasked with creating 7 new fields and updating 15 existing formula fields.. Let’s also assume that no other changes were expected to be deployed to Production at this point. 

Upon receiving an email alert you would expect to see only the name of the admin and list of only those changes. However, this is what shows up:

We can see Kim and Kevin also made some changes. Among changed components we see apex classes, lightning components, report types, applications, field sets and permission sets!

This therefore calls for an investigation as to why these changes were made.

By running a change log report as we did in the previous module (Report on all changes in your Org – Support Article) you can quickly see who has done which changes, and discuss with the team why the changes were made and deployed at this time.

Troubleshooting

Monitoring changes to the Production environment is a great way to get on top of any bugs and identify the root cause of the issue. 

Very often a business stakeholder will raise an issue with someone from the admin / development team that [something] stopped working or that they can no longer see [something]. There could be many reasons for that behavior. A field being accidentally deleted, a profile, permission set or permission set group being changed, etc. Trying to troubleshoot the issue without knowing what was recently changed could take a lot of time and yield very little result.

Relying on alerts or change log reports helps you narrow down, from all the possibilities, the exact set of changes that are most likely to be the culprit for the bug or adverse user experience.

You can learn more about how to use Elements to investigate, troubleshoot and resolve bugs and issues in the Troubleshooting Org Problems (Ref-A206?) course, after you complete this course. 

Click to reveal course link

Troubleshooting Org Problems, opens in new window. ***false link**

Illustrative example:

Click to open illustrative example

Let’s say a business stakeholder contacts you to complain that they can no longer see a particular field on an Account page layout. There are many things that could have caused this and investigating each possibility could take some time. The change log email, coupled with the report you can generate in the Org Model, will help you narrow down the specific types of changes that could have caused it, saving you time and accelerating the resolution.

In the report, which we grouped by parent object API name and type, we can see that no page layouts were changed on the Account object. This means we will need to look into either the permission changes or the record type changes. 

Conflict

If you use a sophisticated DevOps tool for Salesforce like Gearset or Copado then you are likely already taking care of addressing conflicts in deploying or making changes. However, if you rely on change sets or simple mass-deployment tools then alerts on Production Org changes can save you another headache. 

A conflict occurs when multiple changes to the same metadata would result in some of the changes being overridden and lost. This often happens when multiple people touch the same metadata in multiple Sandboxes or when a change was made to the target metadata in Production Org after a Sandbox was created for a particular project. 

Being aware of when a Production Org is changed is an easy trigger to investigate if your planned change or deployment may be at risk of overwriting someone else’s work.

Illustrative example:

Click to open illustrative example

Chris, Suzanne and Charlotte are all making changes on the Account object in three separate Sandbox Orgs. As it happens, the changes they are doing will all require updates to the same profiles (access to new page layouts and fields). 

If they were to deploy their changes to the Production Org, they would have overwritten each other’s work one by one. But with the Production Org change log emails, they can be prompted to do a quick investigation of the changed metadata. They can then either refresh their sandboxes or plan to perform certain changes straight in the production org to avoid any work being overwritten and lost. 

User update emails

You can choose which users receive the daily, post-sync email update about all the changes in your Org. You can use that to make sure your team and all relevant stakeholders are never caught off guard by some changes. Furthermore, you can also set up a Slack channel to receive those updates instead.

 

What’s next

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.