Data Governance practice questions

Purchasing a third-party ETL tool.

Why it fails: Buying a tool is a procurement decision, not a governance activity. Without clearly defined data quality standards, an ETL tool will simply propagate existing bad data into the new system more quickly. Effective governance must precede tool selection to ensure the technology aligns with the organization's specific data quality objectives.

Creating more profiles in Salesforce.

Why it fails: Creating more profiles increases administrative complexity and does not address data quality. Profiles control access but do not validate the contents of the data itself. Relying on profiles to manage quality is a misguided approach that often leads to "permission creep" and makes the organization's security posture significantly more difficult to manage.

Renaming all custom fields to match.

Why it fails: While naming conventions are part of good metadata management, they have no impact on the actual data quality or the functionality of a firewall. Focusing on field names instead of the actual content of the data misses the fundamental requirement of improving data accuracy, consistency, and reliability for business users.

Salesforce Setup Audit Trail logs.

Why it fails: The Setup Audit Trail tracks changes to Salesforce configuration, not record-level data lifecycle actions. It would show if an admin changed an Apex class, but not if the class successfully deleted the records as intended. Therefore, it is insufficient for proving that specific data was archived or purged on schedule.

Field-level security settings.

Why it fails: Field-level security controls who can see or edit data, not how long that data resides in the system. While important for access governance, it has no impact on retention. An auditor looking for retention enforcement would find this information irrelevant to the scope of data lifecycle management compliance.

Object-level security profiles.

Why it fails: Object-level security dictates permissions for creating, reading, updating, or deleting objects. It is an access control mechanism, not a lifecycle management tool. It does not provide any evidence that records were purged after seven years, making it an invalid proof for retention policy compliance during an audit.

Automating end-user password resets.

Why it fails: Password management is an operational security function, not a technical debt reduction activity. Automating it helps with user satisfaction and security, but it does nothing to address the architectural complexity, code quality, or system design issues that represent technical debt in the Salesforce implementation.

Increasing the daily API call limit.

Why it fails: Increasing API limits is a capacity planning activity. It provides more room for integration, but it does not fix inefficient integrations that cause the high usage in the first place. Relying on increased limits instead of optimizing code or integrations is a sign of poor governance and increasing debt.

Field-Level Security (FLS).

Why it fails: Field-Level Security restricts access to fields based on profiles or permission sets but does not perform data masking. If a user has access to a field, they see the actual value, not a masked version. It is an access control mechanism rather than a data transformation tool.

Dynamic Forms.

Why it fails: Dynamic Forms allow architects to conditionally show or hide fields on page layouts based on record values or user criteria. This functionality manages visibility but does not mask the actual data contained within the field, meaning the data remains visible in reports, list views, and API calls.

Validation Rules.

Why it fails: Validation rules are used to enforce data integrity and formatting requirements during record creation or updates. They do not have the capability to obfuscate or mask data values at the UI layer, nor can they dynamically modify the data presentation based on the user's role.

Validation Rule that checks the user's permission set

Why it fails: A validation rule can prevent saving a record based on a condition, such as checking if the user lacks a permission set. However, it would not prevent the field from being edited in the UI or API; it would only block the save operation. This is a reactive control and does not provide the clean, proactive restriction required, and it may cause user frustration with error messages.

Field-Level Security (FLS) on the User Profile

Why it fails: Field-Level Security on the User Profile can restrict edit access to all users with that profile, but it cannot selectively allow edit access only for users with a specific permission set while denying it to others on the same profile. The requirement is to allow editing only for those with the 'Data Steward' permission set, so FLS alone on the profile would not meet the need because it applies uniformly to all users with that profile.

Page Layout with the field set to Read-Only

Why it fails: Page layouts control the visibility and editability of fields on the user interface, but they do not enforce security at the API or data level. A user could still edit the field through the API or by changing the page layout assignment if they have the necessary permissions. Page layouts alone cannot restrict editing to a specific permission set; they are a presentation layer, not a security mechanism.

Data Loader logs

Why it fails: Data Loader logs record the success or failure of data loads performed by that tool, including the number of records processed and any errors. However, these logs are stored locally on the machine running Data Loader and are not centrally managed in Salesforce. They also do not track changes made by other tools or integrations, and they lack the granularity to show old and new field values for audit purposes. They are not a governance-grade solution.

Event Monitoring

Why it fails: Event Monitoring provides detailed logs of user activity, including API calls, page views, and report exports. While it can show that a user or integration accessed the field, it does not capture the old and new values of a field change. It is more about security and usage analytics rather than data lineage. It could help identify the integration job, but not the specific field changes, so it falls short of the full requirement.

Setup Audit Trail

Why it fails: Setup Audit Trail tracks changes to metadata and configuration, such as user permissions, custom fields, and workflows, not changes to individual record data. It would show when the field was created or modified in setup, but not when a record's value was updated by an integration. Therefore, it does not meet the requirement to track data changes to the Customer_Health_Score__c field on records.

Set the object-level permission for the diagnosis object to Read Only for all profiles.

Why it fails: Object-level Read Only still permits users to export records through reports, list views, and Data Loader if they have the API Enabled and Export Reports permissions. It restricts create, edit, and delete, not export. The policy requires preventing export specifically, so this setting does not satisfy the requirement even though it limits write access.

Create a permission set that grants View All Data but not Modify All Data on the diagnosis object.

Why it fails: View All Data broadens record visibility and does nothing to restrict export. Users with this permission can still run reports and export results. The governance policy is about preventing data exfiltration, not about widening visibility, so this permission set moves in the opposite direction of the requirement.

Remove the Export Reports permission from all profiles and disable the API Enabled permission org-wide.

Why it fails: Removing Export Reports and disabling API Enabled would block many legitimate integrations and administrative tasks, causing widespread operational impact. It is a blunt control that violates the requirement to preserve legitimate record access and normal platform use. A targeted Transaction Security policy is preferable because it blocks only the prohibited export behavior.

Classic Encryption with a masked view for all users and a separate permission set granting unmasked access, combined with Event Monitoring for access auditing.

Why it fails: Classic Encryption masks the field for all users and does not support granting a subset of users unmasked access through a permission set. Its masking is effectively all-or-nothing. The scenario requires that authorized agents can view full values, which Classic Encryption cannot support, so it fails the functional requirement despite addressing masking.

Field-Level Security to hide the field from unauthorized profiles and Field Audit Trail to track changes to the field value.

Why it fails: Field-Level Security removes the field from layouts and API access for unauthorized users, but it does not mask the value for users who can see the field, and the scenario requires masking for most users. Field Audit Trail tracks value changes, not read access, so it does not satisfy the auditability requirement for viewing unmasked data.

Salesforce Shield Platform Encryption with a deterministic encryption scheme and a permission set controlling decryption access.

Why it fails: Platform Encryption protects data at rest and in the database, but authorized users who can view the record still see the decrypted value in the UI. It does not provide the selective masking experience described. The scenario requires that most users see masked values while a small group sees full values, which is a presentation-layer control, not an encryption control.

Enable Shield Platform Encryption for all fields.

Why it fails: Encryption is a technical control, not a governance framework. Implementing encryption without a classification policy leads to performance overhead and operational complexity. Governance must dictate which data requires encryption, whereas this option skips the strategic planning phase necessary to identify high-risk data elements requiring specific technical safeguards.

Implement Field Level Security on all PII fields.

Why it fails: Field Level Security is a tactical implementation tool. Without a governance framework to categorize PII, administrators may inconsistently apply settings. Governance ensures that policies define who has access, while technical settings are merely the enforcement mechanism; focusing solely on tools ignores the strategic oversight required for comprehensive data integrity.

Automate data purging using Apex triggers.

Why it fails: Automated purging is a lifecycle management activity, not a classification governance component. While lifecycle management is part of a broader strategy, it fails to address the identification and categorization of sensitive data. Implementing automated logic without governance often results in the accidental deletion of business-critical or legally required records.

Define the overarching corporate data strategy.

Why it fails: Defining the corporate data strategy is the responsibility of the Data Governance Council or Chief Data Officer. Data stewards operate at the tactical and operational level, executing the strategy rather than defining it. Their focus is on specific data domains rather than the organization-wide high-level vision and objectives.

Design the technical Salesforce architecture.

Why it fails: Designing the technical architecture is a role for Salesforce Architects. While stewards provide requirements, they do not possess the responsibility for platform scalability, integration patterns, or security infrastructure design. Confusing these roles can lead to poor technical designs that fail to meet the performance needs of the business.

Approve all system-level security access.

Why it fails: Security access management is typically handled by System Administrators or Security Officers based on defined roles. Data stewards might recommend access levels based on data sensitivity, but they do not hold the authorization to approve system-level security configurations, as this creates a conflict of interest in access control.

Increased latency in database query execution.

Why it fails: Governance policy misalignment does not inherently cause query latency. While excessive security layers can impact performance, a policy document itself is just metadata. Latency issues are typically caused by inefficient SOQL, overly complex sharing rules, or heavy automation, rather than the existence or failure of a data governance policy.

Loss of data due to automated purging.

Why it fails: The exhibit describes a masking and access policy, not a data retention or deletion policy. Masking rules prevent unauthorized viewing; they do not trigger the removal of records. Therefore, misalignment here does not directly lead to data loss, but rather to unauthorized data exposure or privacy violations.

Increased storage consumption in the Org.

Why it fails: Data masking policies do not increase storage usage. Masking is a presentation-layer or access-layer modification that changes how data is displayed to the end-user. It does not create additional records or store extra characters in the database that would consume organizational data storage limits or file storage capacity.

User Access Request Log.

Why it fails: An access log is an operational document used for security audits after the fact. It does not provide the structural information necessary to determine where data is stored. Relying on access logs for data residency compliance is insufficient because they do not document the physical location of the underlying data records.

Service Level Agreement (SLA).

Why it fails: An SLA defines the expected performance and availability of a service between a provider and customer. It does not govern the regulatory requirements regarding where data is stored. Using an SLA for residency compliance is inappropriate as it lacks the technical detail needed to manage regional data storage obligations.

Salesforce Org release notes.

Why it fails: Release notes describe updates, new features, and bug fixes provided by Salesforce. They are not organizational documents that detail how a specific company handles its internal data or where it chooses to store that data to meet legal requirements. They contain no information relevant to the company's specific data residency strategy.

Managing daily Apex deployment cycles.

Why it fails: Deployment management is a technical task for the DevOps or Release Management team. The governance council is a strategic body that focuses on policy and data quality, not the technical mechanics of software delivery. Including operational tasks in the council's scope distracts from high-level decision-making and leads to inefficiency.

Directly configuring Salesforce security profiles.

Why it fails: Security configuration is the domain of system administrators and security architects. The council sets the policy that requires security, but they do not perform the hands-on configuration themselves. Direct involvement in system-level tasks by the council would result in operational bottlenecks and deviate from their strategic leadership mandate.

Centralized Governance.

Why it fails: A purely centralized model often becomes a bottleneck for large, global organizations. It forces a 'one-size-fits-all' approach that often fails to accommodate the specific regional or functional needs of diverse business units. This can lead to resistance from business users and result in shadow IT implementations that bypass governance.

Decentralized Governance.

Why it fails: Decentralized governance leads to data silos and inconsistent definitions across the enterprise. Without a central body to enforce standards, each business unit creates its own rules, making it impossible to consolidate data for reporting. This fragmentation defeats the purpose of governance and undermines the organization's ability to drive strategic insights.

Automated Governance.

Why it fails: Automation is a tool, not a governance model. You cannot automate governance without a predefined framework, and applying automation blindly across diverse business units often results in incorrect validation or data loss. A model must first be chosen to define the structure before technical automation can be effectively deployed.

Data Creation.

Why it fails: Archiving during creation is illogical as the data is actively being used. The goal of creation governance is to ensure that data is captured accurately and with all required metadata. Archiving at this stage would prevent the data from being available to users, rendering it useless for business operations.

Data Usage.

Why it fails: Data usage involves reading and updating records. Governing the usage stage ensures that access is controlled and that the data remains accurate. Archiving during active usage would disrupt business processes and prevent users from accessing the information they need to perform their daily tasks, creating unnecessary operational friction.

Data Acquisition.

Why it fails: Acquisition focuses on data ingestion and validation. Governance at this stage is meant to ensure that only quality data enters the system. Archiving during acquisition is a contradiction, as the goal is to integrate data into the system, not to immediately move it out to secondary storage locations.

Enforcing record-level security.

Why it fails: Record-level security is managed through sharing rules, roles, and profiles. A data dictionary is a documentation asset, not a security enforcement mechanism. It provides context to users, but it has no technical capabilities to prevent unauthorized access or restrict what a user can view or edit in Salesforce.

Automating data cleaning processes.

Why it fails: Data cleaning requires logic and automation tools, whereas a data dictionary is a reference document. While the dictionary informs what the data should look like, it cannot perform the actions required to fix or cleanse the data. Relying on documentation to perform technical tasks is a common architectural misunderstanding.

Managing integration authentication tokens.

Why it fails: Authentication tokens are part of API security and identity management. A data dictionary has no function related to securing integrations or managing credentials. Confusing documentation assets with security components leads to significant architectural gaps and makes the system vulnerable to unauthorized access and management errors.

Using Duplicate Rules to merge records.

Why it fails: Salesforce duplicate rules are great for tactical cleanup but are not sufficient for enterprise MDM. They lack the logic to reconcile data across disparate external systems. Relying solely on platform tools for MDM ignores the need for cross-system orchestration and centralized data stewardship required for a true Golden Record.

Creating custom formula fields.

Why it fails: Formula fields are for displaying data, not for master record reconciliation. They do not store data, nor do they provide the synchronization logic necessary to integrate with other business systems. Using formula fields for MDM is a fundamental misunderstanding of the platform's capabilities and will result in significant data inconsistencies.

Enabling Person Accounts for all users.

Why it fails: Person Accounts are a data model choice for B2C organizations. Enabling them does not resolve conflicts between systems or establish a 'Golden Record'. It is a structural platform configuration that has nothing to do with the governance or logic required for effective Master Data Management across the enterprise architecture.

Data Classification Policy.

Why it fails: Data classification defines sensitivity and security handling. It has no role in the change management or feature deployment process. While important for security governance, it does not provide the structure needed to manage platform updates, test for breaking changes, or ensure that the application remains functional after releases.

Data Dictionary.

Why it fails: A data dictionary documents the meaning and structure of data elements. It does not contain information about Salesforce release features, deployment methodologies, or testing protocols. Relying on a data dictionary to manage platform updates is inappropriate as it lacks the procedural guidance required for a successful, low-risk release cycle.

Master Data Management (MDM).

Why it fails: MDM is focused on the consistency and quality of core business data entities like customers or products. It is not designed to manage software releases or the impact of platform upgrades on custom logic. Its scope is entirely different from the technical change control required for managing Salesforce platform updates.

Increased system storage limits.

Why it fails: Invalid data format errors are usually triggered during the record save process. They do not impact the physical size of the data stored in the database. Whether the lead is 'invalid' or 'valid', it consumes approximately the same amount of storage space within the Salesforce Org's total limits.

Inability to run system reports.

Why it fails: Reports will still execute even if the data inside them is malformed or invalid. The report might return inaccurate or misleading results, but it will not fail to run because a specific validation rule is inactive. The risk here is data quality and trust, not the operational failure of the reporting engine.

Increased Apex trigger execution time.

Why it fails: Validation rules are declarative and execute during the database save sequence before triggers. Turning them off actually reduces the total work the database needs to perform during a save. Therefore, an inactive rule will not increase trigger execution time; it will potentially decrease the overall transaction processing time slightly.

List of user profiles.

Why it fails: A list of profiles is a tactical security configuration document. While it shows how access is assigned, it does not demonstrate the existence or effectiveness of a broader data governance program. It only provides information on current permission settings, which is insufficient for proving overall data governance policy compliance.

Salesforce Developer Guide.

Why it fails: The Developer Guide is a technical manual for Salesforce platform features. It is not an organizational document and has no relevance to the specific policies, procedures, or governance controls that a company has implemented. Using it as proof for an auditor would clearly demonstrate a lack of real data governance.

Individual user training materials.

Why it fails: Training materials demonstrate awareness, not the existence of a formal governance framework. While training is a component of change management, it is not a governance artifact. Regulators want to see policy and structure, not how-to guides for end-users, as the latter does not prove that data is being managed strategically.