0
M
Snapshots
0
M
Deployments
0
M
Reports
Menu
Snapshot provides over fifty reports for security and compliance reporting.
Snapshot documents every aspect of the change and release management process. This information is useful for administrative governance during the release process and is also available as a permanent record for compliance. These documents can be stored as custom objects in your Salesforce account, saved as local files, or stored as Salesforce Content. Documenting this information for every org can greatly improve Salesforce compliance, governance and security.
Snapshot also provides two dozen automated reports that are hugely beneficial for release management as well as corporate compliance, governance and security. These reports are available in CSV, HTML, and PDF format. They can be branded with a corporate logo and additional information. They can be sent as email attachments or Chatter Content. All of these reports can be scheduled and automated. Many of them have conditional triggers and are sent out only when problems are detected.
This white paper discusses common use cases for improving security and compliance reporting at your company. This information should be helpful for Salesforce administrators, compliance managers, and security professionals.
Here is an overview of the different documents and reports that Snapshot provides. Each individual report is discussed in detail in the sections below:
Compliance Documentation
Metadata Reports
Data Usage Reports
Security Reports
Each time a metadata snapshot is taken, the information is added to a time series. By virtue of simply using the Snapshot product, an administrator creates a time series record of all of the metadata changes in an org over time. The snapshots in the time series can be compared on a line by line basis, and you can run reports on any of the snapshots in the time series.
Each snapshot file contains a wealth of information about the state of a Salesforce account. The Metadata API, the Data API, the Tooling API, and the Force.com REST API are all used to collect information. The Metadata API captures the selected metadata assets. The Data API gathers Describe data on the selected Custom Objects. The Tooling API downloads additional information about creation and modification dates. The Force.com REST API records the organizational limits.
This information is automatically maintained on the client desktop computer where Snapshot is installed. All of the data is in the “storage” folder next to the snapshot.mzoa file. Each item on the Snapshot desktop has a corresponding folder that contains the time series data. The snapshot file can be automatically sent in email or saved to a repository as part of the scheduling and automation process. This information provides a foundation for compliance, and is also a necessary resource for the backup and recovery of the Salesforce org.
When a deployment is made, Snapshot adds all of the information about the deployment to two Custom Objects that are installed by our Managed Package in the licensed org. The Deployment History objects are used by administrators to verify that a given snapshot is up to date, to review historical deployments, and to work with previously used Create and Delete Job Lists. There is also a Deployment Report that is created for any deployment. This is a text version of the Deployment History objects. The Deployment Report is often sent as a human readable email when a deployment succeeds, fails, etc.
The name of the Custom Objects is metazoa3__snapshot_push__c and metazoa3__snapshot_asset__c. The snapshot_push object is the Master, and the snapshot_asset object is the Detail. The snapshot_push Master Object contains all of the information about the push: the source org, the destination org, the person conducting the deployment, the Create Job List, the Delete Job List, and all of the various settings for the push. The snapshot_asset Child Object contains all of the individual assets contained in the Create and Delete Job List.
The Deployment History can be searched and reported on in the Salesforce HTML interface. Workflow triggers can be created to alert administrators that a deployment has occurred when these objects are created. These objects capture any push by the Snapshot product between any two orgs, and so they contain a complete picture of all administrative activity with Snapshot. Below is a picture of the snapshot_push object in the Salesforce HTML interface.
Each time a metadata snapshot is taken, the information is added to a time series. The Time Series Differences report can compare any two snapshots in the time series. This provides a complete picture of all metadata changes in the org over time. The report can drill down into sub-types as well. This can show, for example, the date and time that an admin added individual Fields to an Object. This report is available for any Salesforce org or any developer project stored in a repository.
The Time Series Difference report can be scheduled. For example, the report might calculate metadata differences after a nightly snapshot of the org is taken. The report can be sent out to administrators as an email attachment or Chatter Content. The Schedule Report tab has an option to make this conditional, and only send the message if differences are detected. Used in this manner, the Time Series Differences report can automatically document metadata changes in an org and notify administrators.
There are a variety of compliance and governance use cases for this capability. First, if a group of developers are working on a particular project, the differences report documents all progress as assets are added to the org or developer repository. Second, the developers might use this report to catch unwanted or accidental changes to any section of metadata. Perhaps another development team changed something, or an employee used the Setup Menu. Lastly, any compliance organization wanting a dynamic update on metadata changes could use these report for that purpose.
The Metadata Differences report is similar to the Time Series Differences report, but instead of looking at one org over time, this report looks at the differences between two orgs connected by a deployment arrow. The report specifies the number of differences for each metadata type, and the top slide down panel allows an administrator to drill down into the line by line details.
This report can be used to explore the exact differences between two Salesforce orgs, or a developer project and a Salesforce org. For example, if an administrator is getting ready to migrate a Sandbox into Production, then they could use this report to explore and document the differences before migration.
In the example below, you can see all of the differences between the Custom Objects in two connected Salesforce orgs. The Custom Object Adam_Bar__c is showing a total of 7 differences. Slide down the top panel, and you can drill down into every difference on a line by line basis. The first difference shows that the destination org has the extra field Build_Date__c defined in a compact layout. You could select the metadata sub type Compact Layouts from the lower left list to further target those differences.
Think for a second about your production Salesforce account. Most orgs will have Custom Tabs, Page Layouts, Custom Objects, Profiles, Visualforce Pages, and many other configurations. The Metadata API currently supports about 150 different types. And for each type, there are many individual assets. An Unlimited Edition org can have up to 2000 Custom Objects, each with a maximum of 500 fields. There can be hundreds or even thousands of Roles, Profiles, Dashboards, and other assets.
Now think about this. Where did all that stuff come from? Who deployed it? When was it deployed? Was it tested in a Sandbox? Was it modified with the Setup Menu? What was the chain of custody from the original developer who created it down through various Sandboxes and other staging orgs before it ended up in your production account?
The new Asset History Report can answer these questions. This report mines the “meta metadata” that Snapshot stores in the licensed org along with additional information from the Salesforce Metadata, Tooling, and Data API. As a result, the Asset History Report can tell you where each metadata asset was originally created, what changes were made to the asset, who made these changes, which orgs the asset moved through, and when the asset was last modified. This is a game-changing report for compliance, security, and governance.
The Similar Assets report shows the number of differences between assets of the same metadata type. For example, you might find that some Reports are identical in your org. This report is often used to find duplicate Custom Objects, Profiles, and Page Layouts as well. The top slider provides line by line detail of all differences. The Similar Assets report is useful for cleaning up duplicate assets and understanding the metadata structure of your account.
The Org Dictionary can be used to report on all 250 different metadata types. The elements in each metadata type can be selected and the columns can be ordered depending on your business process. Individual cells can also be color coded by value. The Org Dictionary is a very powerful solution for compliance reporting on all the metadata types in an org. The Data Dictionary has specialized capabilities for reporting on Custom Objects and Custom Fields. The Data Dictionary is discussed in the next section.
The Data Dictionary report is used to provide complete documentation on the state of Custom and Standard Objects in your org. Any number of Objects can be selected for the report. Then the report can be customized to include Summary Statistics, Organization Limits, Object Properties, Field Properties, Object Relationships and Field Relationships.
The Organization Limits include 20+ limits such as Daily API Requests and Daily Storage MB. The Object Properties include 50+ different Object properties such as Label and Description. The Field Properties include 80+ Field properties such as Inline Help Text and Formula. The Object and Field Relationships show how the given Object or Field is related to any of the other metadata types.
The Data Dictionary is a key report for compliance and documentation. Companies often archive this report to document the state of their org over time. All of the columns in the report can be customized to provide only the information that a company deems relevant for compliance. System Integrators often present this report to customers to document the current state of the org.
The Relationship Matrix report is mainly designed to provide an interactive understanding of the metadata structure of an account. How do Reports relate to Custom Objects? How do Dashboards relate to Reports? All of these questions can be explored and documented. This report is often used to untangle complex relationships between metadata assets in the org.
The Fields Vs Page Layouts report documents which fields are on which page layout. Each field can be required, editable, read only, or missing. This is a useful report for compliance and documentation. When looking at any column, you can see all of the status of every Field on the Page Layout. When looking across any row, you can see which layouts an individual Field appears on. This report is often used to verify that a particular Field appears on some Page Layouts but not on others.
The Record Types Vs Picklists report shows how the Picklists for any object are modified by all of the Record Types for that Object. On the first column, you can see all of the Picklist values, and then on each Record Type column after that, toy can see how the Picklist changes. This is helpful in understanding the metadata structure of your org and preventing errors when Record Types and Picklists get complex.
This report places information about controlling and dependent Picklists in an easy to read tabular format. This is helpful in understanding the metadata structure of your org and preventing errors when controlling Picklists get complex. Both the controlled values and the uncontrolled values are listed in the report.
The Field Usage report examines a set of records from any Standard or Custom Object. The set can include all records, records chosen by name, or records selected with a filter. Then the report examines each field in the selected Object. The report shows the total number of fields, how many fields are equal to the default value, how many fields are empty, and how many fields have distinct values.
The Field Usage report can also interactively list the least and most popular values for any selected field. On the one hand, this capability helps an administrator drill down on unique or aberrant field values, and on the other hand, this capability provides an easy way to see overused or duplicate values.
This report is extremely useful for finding rarely used or misused fields in any object. Fields that are less distinct (and therefore more uniform) should be looked at closely. Sometimes they are mainly empty. Other times they might be rarely used, forgotten, or neglected. In other cases, a lack of Distinct values might be appropriate. For example, company zip codes will be less distinct than company names.
This information could suggest policy problems, corrective actions, or administrative changes. Perhaps an unused field should simply be deleted. The sales team almost never fills in the Customer Website Field when a new account is created. Should this be a required Field? Missing or empty data can also point to upstream data entry, external integration, or website problems.
The Picklist Usage report examines a set of records from any Standard or Custom Object. The set can include all records, records chosen by name, or records selected with a filter. Then the report examines each Picklist in the selected Object. The report shows the total number of Picklist values, and how many times each Picklist value is being used in the record set. The report can also be expanded to break down Picklist usage by each Record Type in the Object.
This report is extremely useful for finding rarely used or misused values in any Picklist. The Other Values column (pictured below) shows miscellaneous values that are not actually in the Picklist. This is useful for discovering new values that should be incorporated into the Picklist, and also for cleaning up Picklist data that contains with the wrong value.
This information could suggest policy problems, corrective actions, or administrative changes. Perhaps an unused Picklist value should simply be deleted, or maybe one of the Other Values needs to be added to the list. Examining Picklist usage by Record Type is also useful. You can see which Record Types are using what Picklist values.
The Last Activity Date report allows an administrator to select a set of Dashboard, Report, or Email Template records. The set can include all records, records chosen by name, or records selected with a filter. Then the report calculates when each Dashboard, Report, or Email Template was first created and most recently used. This information can be used to weed out old and stale assets that are clogging up your org. Any Dashboard, Report, or Email Template that has not been used in years is also likely to contain inaccurate information.
Reports have information about last run date. Dashboard have information about Last Refresh Date. Email Templates have information about Last Used Date and the number of Times Used. All of these objects have Created Date and Last Modified Date. All of these dates are used to calculate the First Activity and the Last Activity dates on the right-hand side of the report. Taken together, an administrator can use this information to figure out which the old assets should be deleted.
The Apex Code Coverage report allows an administrator to select any number of test classes on the Select Apex Tests tab, and then see all of the test results on the Display Report tab. The Code Coverage tab displays the line by line coverage details for the Apex Tests, Apex Classes, and Apex Triggers in the report. Lastly, the Schedule Report tab can be used to automate this report, and conditionally send the report out only if Low or Medium coverage is detected.
The Select Apex Tests tab can be used to examine the effect of running a single test class. The Apex Classes and Triggers that are covered will be displayed, and the coverage results will be detailed. You can also select multiple Test Classes to run, and see the aggregate results on the Display Report tab. This is useful if you want to focus on a group of classes and see their code coverage without running other tests. If all Apex Tests are selected, then the Display Report tab shows the Apex Classes and Triggers that are covered, but also includes other Classes and Triggers which are not covered by any test class.
The Manage Coverage button at upper right allows an administrator to edit the code coverage levels used for report colorization and the conditional threshold. The use case here is that a development team can set up the report to watch a set of Apex Classes and Triggers they are working on. If the nightly code coverage for any script falls below the desired standard, then they are automatically notified. The report could also be run on a production org and document compliance with code coverage standards after each metadata update.
The Record Level Security report examines a set of records from any Standard or Custom Object. The set can include all records, records chosen by name, or records selected with a filter. Then the report calculates which users have access to each record, what kind of access, and the reason why.
Because some large orgs have many thousands of users, the report details access by Profile, Permission Set, Sharing Rule, Object Ownership, Group Membership, and Role Membership. The Preview Report tab allows an individual record to be selected and will interactively display the entire set of users with access to that record, along with a more detailed reason as to why access was granted.
The value of this report for security and compliance can’t be overstated. Any object that contains sensitive information can be analyzed. The set of people with access to that object are displayed. If one particular record has been compromised, then the entire set of users with access to that specific record will be generated. Instead of wading through the sharing rules, permission sets, manual shares, and role hierarchy at your company, this report provides a machine generated method of verifying and explaining object visibility across any group of users.
The User Activity Timeline report shows all of the activities that a given user performed during a specified time frame. This report mines information from many different Salesforce objects and systems in order to paint a complete picture of user activity. This information can be used to monitor user activities and trigger alerts if problems are detected, or the report can be used forensically to investigate an incident in the past for security or governance purposes. The User Activity Timeline report is a key security capability for any Salesforce org.
An administrator can select different Objects for the report, a group of Users, and a start and stop date for the timeline. The Objects include the EventLogFile, LoginHistory, SetupAuditTrail, Standard Objects, and Custom Objects. The EventLogFile is a special capability that must be purchased from Salesforce. This Object has over 40 different types of event logs, including data exfiltration information. The LoginHistory Object documents user logins and failed attempts. The SetupAuditTrail Object records over 40 different types of administrative user actions performed with the Setup Menu. The Standard and Custom Objects show when the user created or last modified an Object during the time frame.
An administrator can set the risk level of each activity to Low, Medium, or High. If any activity exceeds the threshold, a report is sent out documenting the user activity for the given time frame. The use cases here are compelling. The activities of a troubled employee can be monitored before and after termination. The activities of an employee that leaves unexpectedly can be evaluated in retrospect. This report can also be used to keep a watchful eye on any external consultant or developer with org access.
The Security Health Check is the same as the Salesforce report available in the Setup Menu. However, this report can be can scheduled, and trigger exceptions if a Medium Risk or High Risk event is detected. If an unacceptable security problem is detected after metadata changes then an administrator can be alerted to the problem automatically.
The Profiles and Permission Sets report shows all of your Profiles or Permission Sets down the left-hand column and the selected metadata sub types across the top. The sub types include: Apex Page Accesses, Apex Page Accesses, Application Visibility, Field Permissions, Layout Assignments, Object Permissions, Record Type Visibility, Tab Visibility, User Permissions, and Custom Permissions.
These reports document all of the characteristics of your Profiles and Permission Sets in a single easy to read tabular report. Looking down any column will show the permissions for a single metadata asset by Profile or Permission Set. Reading across any row will show the permissions for a single Profile or Permission Set by each metadata asset. The report can be saved either in HTML, PDF, or CSV. As usual, all of these reports can be scheduled and automated for archive or email purposes.
The last section of the Profiles and Permission Sets dialog provides additional information about the Combined Security permissions granted to individual users. The administrator can select any set of Users in the org. The Users will be listed down the left-hand side of the report table. The metadata sub types are displayed across the top, just like the Profiles and Permission set reports.
The Combined Security report starts with the base Profile and then overlays the various Permission Sets assigned to each user. The combined permissions, shown at the bottom of each cell, represent the actual privileges that are being granted. Green cells show where the Permission Sets have changed the base Profile privileges, and Red cells show where the Permission Sets did not change anything.
In the example below, an administrator has selected the Combined Security Object Permissions report. The Profile assigned to user Josh Hyde does not grant any access to the Account object. But Josh has also has been assigned three Permission Sets that overlay additional privileges. The Combined Security permissions shown that Josh actually has Create, Delete, Edit, and Read access to the Account Object.
This whitepaper has discussed some of the common ways that companies use Snapshot to enhance compliance, governance, and security on the Salesforce platform. Snapshot provides a best-of-breed solution to enable effective release management through streamlined deployments. Over two dozen reports are available to improve compliance, governance, and security at any company. Click the download button to get the pdf version of this report.
© 2018-2024 Metazoa. All rights reserved. Proudly made in California
Congratulations! 