Compliance
April 29, 2021
Common gaps in Salesforce data governance and how to avoid them
Good data governance helps prevent errors in your Salesforce instance
.jpeg){kind=avatar}
Data governance is the strategy for a company’s data defining who is responsible for the data and how it may be used. Having a solid plan ensures data consistency across your technology stack and prevents errors so you can reliably deliver solutions to users.
In addition to the benefits of a broader Salesforce governance strategy, data governance helps prevent errors in your Salesforce org. Depending on the type of data, you may not know things are screwed up right away. If it’s metadata like a piece of code or a field that was never created, you’ll probably find out very quickly. But if it’s an inactive configuration record that was accidentally changed to active, or a small change to a different configuration, it may be days or even months before you find out. All the while those undetected errors can have a serious impact on your business. Remember that time a price rule was inadvertently reactivated or when a change extended your contract terms erroneously?
Governance processes are needed for all types of data. Even the data that helps you make more data. The below types of data are commonly included in governance processes within your Salesforce landscape:
Metadata is best known as the data about data. It describes the properties of data, like when the data was created, where and by whom, for example. It includes summaries about the types of data within your organization and how it is leveraged in your solutions. Common examples include Fields, Objects, Workflows, etc. Whether it is a common item included in standard applications like the Salesforce Sales Cloud or custom items that are unique to your organization, metadata includes things that are created programmatically (with code) or declaratively (without code).
Also called configuration data, reference data defines the rules for other data. Not to be confused with metadata which describes properties of data, reference data defines the allowable limits for other data. Reference data describes how other data can be used; that is to say, how it’s referred to in order to ensure a result is allowable. For example, reference data can define rules for pricing, so the price of a product or service never exceeds a set limit.
In low-code managed packages such as Field Service, Revenue Cloud, FinancialForce, and Conga Contracts, reference data includes objects like Products, Price Rules, Employee Skills, Templates, and Company Codes. Reference data is created as administrators point-and-click their way through the configuration that allows apps to work.
Transaction data is the fuel that helps run your company. It captures the day-to-day interactions your business has with prospects, customers, partners, and vendors. For a sales organization, this includes Leads, Customer Accounts, Contacts, Quotes, Orders, Cases, Invoices, etc. For a purchasing organization, it could include Vendors and Contacts. Transaction data can be created internally by employees, or externally by customers and vendors within a community or through electronic data interchange (EDI) with the customer’s online transaction processing system.
Some transaction data is leveraged across applications within your Salesforce landscape and can be integrated with platforms outside of the Salesforce ecosystem, such an ERP or accounting system. For organizations who leverage multiple online transaction processing systems, this data is often integrated across platforms leveraging a middleware tool, and there are master data management (MDM) solutions in the marketplace to maintain a source of truth for this data.
Transaction data is the key to running your company, so it’s important to identify areas of potential exploitation—intentional or not—and design a governance policy to protect your business. Could a disgruntled employee export your entire customer list? If an internal process broke would you still be able to sell and service customers?
Governance is especially critical for data related to individuals to ensure compliance with a growing number of data privacy laws and regulations. Beyond legal compliance, a strong governance strategy for transaction data protects your company from potential fraud, being in breach of contract, and bad customer experiences.
Governing your data will rely on a mixture of people, process, and technology. Depending on the size of your delivery team, you may have a mixture of system administrators, developers, business users, and release managers, who work in tandem to perform data updates. Data governance will ensure everyone properly validates their work and layout the process for how data should be migrated (i.e. as part of a scheduled release) as well as the communication checkpoints to ensure all related departments are aware of the most up-to-date changes.
An industry adopted best practice for Salesforce change management is to perform changes in a personal Developer org or scratch org, migrate those changes into an shared sandbox for testing and validation, and then deploy changes into a production org.
Salesforce is designed to get your users off of spreadsheets, giving your company a central, comprehensive, and always up-to-date view of your business. As part of your data governance strategy, you’ll want to define when it’s appropriate to export data from Salesforce. There are many reasons to not export data, but the security implications of sensitive information ending up in the wrong hands is probably the biggest factor for limiting data exports. When there’s a legitimate reason for an export, your data governance strategy should define where exports should be stored and how long they can be kept before disposing them.
No one likes having to do work twice. Plus, manually rebuilding data in each org create opportunities for mistakes. For metadata, the entire migration process can be managed via Salesforce change sets, but for reference and transactional data, explore Salesforce data deployment tools. This will be particularly useful for managing uniquely challenging reference data relationships, meaning that dependencies between records need to be recreated when deploying into a new org.
When issues arise, it’s very likely that something changed. Having a record of every data change means you can quickly pinpoint and resolve the issue to get users back up and running faster. Get a demo of Prodly to see how we can help you strengthen your data governance efforts.
Data governance is the strategy for a company’s data defining who is responsible for the data and how it may be used. Having a solid plan ensures data consistency across your technology stack and prevents errors so you can reliably deliver solutions to users.
In addition to the benefits of a broader Salesforce governance strategy, data governance helps prevent errors in your Salesforce org. Depending on the type of data, you may not know things are screwed up right away. If it’s metadata like a piece of code or a field that was never created, you’ll probably find out very quickly. But if it’s an inactive configuration record that was accidentally changed to active, or a small change to a different configuration, it may be days or even months before you find out. All the while those undetected errors can have a serious impact on your business. Remember that time a price rule was inadvertently reactivated or when a change extended your contract terms erroneously?
Governance processes are needed for all types of data. Even the data that helps you make more data. The below types of data are commonly included in governance processes within your Salesforce landscape:
Metadata is best known as the data about data. It describes the properties of data, like when the data was created, where and by whom, for example. It includes summaries about the types of data within your organization and how it is leveraged in your solutions. Common examples include Fields, Objects, Workflows, etc. Whether it is a common item included in standard applications like the Salesforce Sales Cloud or custom items that are unique to your organization, metadata includes things that are created programmatically (with code) or declaratively (without code).
Also called configuration data, reference data defines the rules for other data. Not to be confused with metadata which describes properties of data, reference data defines the allowable limits for other data. Reference data describes how other data can be used; that is to say, how it’s referred to in order to ensure a result is allowable. For example, reference data can define rules for pricing, so the price of a product or service never exceeds a set limit.
In low-code managed packages such as Field Service, Revenue Cloud, FinancialForce, and Conga Contracts, reference data includes objects like Products, Price Rules, Employee Skills, Templates, and Company Codes. Reference data is created as administrators point-and-click their way through the configuration that allows apps to work.
Transaction data is the fuel that helps run your company. It captures the day-to-day interactions your business has with prospects, customers, partners, and vendors. For a sales organization, this includes Leads, Customer Accounts, Contacts, Quotes, Orders, Cases, Invoices, etc. For a purchasing organization, it could include Vendors and Contacts. Transaction data can be created internally by employees, or externally by customers and vendors within a community or through electronic data interchange (EDI) with the customer’s online transaction processing system.
Some transaction data is leveraged across applications within your Salesforce landscape and can be integrated with platforms outside of the Salesforce ecosystem, such an ERP or accounting system. For organizations who leverage multiple online transaction processing systems, this data is often integrated across platforms leveraging a middleware tool, and there are master data management (MDM) solutions in the marketplace to maintain a source of truth for this data.
Transaction data is the key to running your company, so it’s important to identify areas of potential exploitation—intentional or not—and design a governance policy to protect your business. Could a disgruntled employee export your entire customer list? If an internal process broke would you still be able to sell and service customers?
Governance is especially critical for data related to individuals to ensure compliance with a growing number of data privacy laws and regulations. Beyond legal compliance, a strong governance strategy for transaction data protects your company from potential fraud, being in breach of contract, and bad customer experiences.
Governing your data will rely on a mixture of people, process, and technology. Depending on the size of your delivery team, you may have a mixture of system administrators, developers, business users, and release managers, who work in tandem to perform data updates. Data governance will ensure everyone properly validates their work and layout the process for how data should be migrated (i.e. as part of a scheduled release) as well as the communication checkpoints to ensure all related departments are aware of the most up-to-date changes.
An industry adopted best practice for Salesforce change management is to perform changes in a personal Developer org or scratch org, migrate those changes into an shared sandbox for testing and validation, and then deploy changes into a production org.
Salesforce is designed to get your users off of spreadsheets, giving your company a central, comprehensive, and always up-to-date view of your business. As part of your data governance strategy, you’ll want to define when it’s appropriate to export data from Salesforce. There are many reasons to not export data, but the security implications of sensitive information ending up in the wrong hands is probably the biggest factor for limiting data exports. When there’s a legitimate reason for an export, your data governance strategy should define where exports should be stored and how long they can be kept before disposing them.
No one likes having to do work twice. Plus, manually rebuilding data in each org create opportunities for mistakes. For metadata, the entire migration process can be managed via Salesforce change sets, but for reference and transactional data, explore Salesforce data deployment tools. This will be particularly useful for managing uniquely challenging reference data relationships, meaning that dependencies between records need to be recreated when deploying into a new org.
When issues arise, it’s very likely that something changed. Having a record of every data change means you can quickly pinpoint and resolve the issue to get users back up and running faster. Get a demo of Prodly to see how we can help you strengthen your data governance efforts.
.png)