Cert++
  1. Home
  3. Platform Data Architect

Platform Data Architect

Checklist progressProgress

0/156Learned

Platform Data Architect Study Checklist
  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Architect
  • Slack Administrator

Checklist progressProgress

0/156Learned

Compare and contrast various techniques and considerations for designing a data model for the Customer 360 Platform

0/15

  • Standard Sales and Service objects versus custom objects for core entities
  • Normalized versus denormalized object design
  • Lookup versus master-detail relationship selection
  • Lookup deletion options and cascade-delete risk
  • Roll-up summary fields versus other aggregation approaches
  • Junction objects for many-to-many relationships
  • Contacts to Multiple Accounts versus custom junction modeling
  • Self-relationships and hierarchical relationships for modeling hierarchies
  • Polymorphic relationship fields versus dedicated lookup fields
  • External ID and unique fields for source-system keys
  • Record types versus separate objects for process variants
  • Person Accounts versus the business Account and Contact model
  • Optional custom object features and their data model impact
  • Salesforce Connect external objects versus copying or replicating external data
  • Relationship types for linking external objects to Salesforce data

Given a scenario, recommend approaches and techniques to design a scalable data model that obeys the current security and sharing model

0/9

Organization-wide defaults for confidential versus non-confidential data

Learn this concept
Unseen

Role hierarchy design for data access and scale

Learn this concept
Unseen

Sharing rules and public group design at scale

Learn this concept
Unseen

Lookup versus master-detail relationships for record access inheritance

Learn this concept
Unseen

Controlled by Parent and implicit sharing on account child records

Learn this concept
Unseen

Field-level security versus a separate restricted object for sensitive data

Learn this concept
Unseen

Object-level View All and Modify All versus org-wide data permissions

Learn this concept
Unseen

Data model requirements for high-volume external user access

Learn this concept
Unseen

Planning sharing recalculation for default changes and mass realignments

Learn this concept
Unseen

Compare and contrast various techniques, approaches and considerations for capturing and managing business and technical metadata

0/5

  • Business dictionary for shared definitions and data ownership
  • Technical data dictionary and ERDs maintained from org metadata
  • Taxonomy design with controlled vocabularies and reference objects
  • Field-level data classification for sensitivity and compliance
  • Data lineage for multi-source records and downstream dependencies

Compare and contrast the different reasons for implementing big objects versus standard/custom objects within a production instance, alongside the unique pros and cons of utilizing big objects in a Salesforce data model

0/6

  • Big objects versus standard and custom objects for high-volume data
  • Big object index design and record identity
  • Loading data into big objects and handling partial batch failures
  • Surfacing big object data in the UI, reports and dashboards
  • Automation and transaction limits when adopting big objects
  • Security, sharing and encryption limits of big objects for sensitive data

Given a customer scenario, recommend approaches and techniques to avoid data skew

0/6

  • Preventing parent-child account data skew in the data model
  • Remediating an existing skewed parent account
  • Ownership data skew and placement of skewed record owners
  • Lookup skew detection and mitigation
  • Relationship field count on heavily loaded objects
  • Reducing record lock contention in bulk loads and integrations
  • Choosing an MDM implementation style for a multi-system landscape
  • Canonical data model for harmonizing multiple source systems
  • Harmonizing and standardizing multi-source data before matching
  • Match methods, attribute weights and confidence thresholds
  • External reference data for enriching master records
  • Hierarchy management for master data in Salesforce
  • Classifying duplicate types before merging or relating customer records
  • Consolidating existing duplicate customer records into a master record
  • Data management plan controls for sustaining a single-org golden record
  • Survivorship criteria for choosing winning attribute values
  • Attribute-level source ownership versus whole-record survivorship
  • Middleware, in-org automation or Data 360 for applying survivorship
  • Data stewardship and business ownership for resolving master data conflicts
  • Source keys and provenance for tracing consolidated customer records
  • Shared data definitions and business metadata for customer rules
  • Reference data stores for consistent customer business rules
  • Salesforce versus Salesforce Platform licenses for internal users
  • Standard versus custom objects for Platform-licensed user populations
  • Permission set licenses layered on a user license
  • Chatter, Identity, and other narrow-scope licenses for limited-access users
  • Integration user licensing for API-only system access
  • Experience Cloud license tiers for external customers and partners
  • Seat-based versus login-based licensing for occasional users
  • License combination for a mixed internal and external user population
  • Enforcing required values across UI, API and import channels
  • Validation rules, field types and restricted picklists for consistent values
  • State and country/territory picklists for standardized addresses
  • Declarative automation versus Apex triggers to normalize data on save
  • Matching and duplicate rules to prevent duplicates at entry
  • Third-party enrichment and data integration rules for accurate records
  • Record locking and all-or-none scope for consistent related-record writes
  • System of record versus system of reference for customer data ownership
  • External ID keys and upsert for correlating records across systems
  • Keeping customer data synchronized across systems of interaction
  • Duplicate merge versus unified profile versus golden record for customer unification
  • Single-org consolidation versus a multi-org strategy for a growing enterprise
  • Hub-and-spoke topology for distributing data across multiple orgs
  • Cross-org adapter virtual access versus replicating another org's data
  • Keeping shared records consistent across orgs with cross-org synchronization
  • Aggregating data from several orgs into a consolidated org or data store
  • Consolidating records from multiple source orgs into one target org
  • Personal, sensitive, pseudonymous and anonymous data in a Salesforce model
  • Individual object for tracking data privacy preferences
  • Consent data model for purpose-specific and channel-specific consent
  • Data subject access and portability request fulfillment
  • Deleting versus anonymizing personal data for erasure requests
  • Data minimization and retention design for personal data
  • Classification-driven protection versus uniform protection of every field
  • Layered access controls versus encryption for restricting who sees personal data
  • Shield Platform Encryption, Classic Encrypted Custom Fields or tokenization
  • Deterministic versus probabilistic encryption for queried personal data
  • Audit and monitoring options for access to and changes on sensitive data
  • Keeping personal data out of sandboxes and test environments
  • Data residency requirements and org strategy for EU personal data
  • Data owner, data steward and data custodian responsibilities
  • Governance council and operating model across business units
  • Standards to define in an enterprise data management plan
  • Declarative Salesforce controls for enforcing governance standards
  • Measuring and monitoring data quality dimensions over time
  • Prioritizing and phasing a governance program rollout
  • Storage option selection by record volume, data location and usage
  • Selective filters for list views, reports and queries on LDV objects
  • Custom indexes for frequently filtered fields on large objects
  • When to use skinny tables on large objects
  • Denormalization to reduce joins and formula-field filters at scale
  • Pre-aggregated summary objects for reporting over millions of records
  • Search design and divisions for text lookups across large objects
  • Sharing model and relationship choices that limit recalculation at scale
  • Lookup skew under concurrent high-volume inserts and updates
  • Integration extraction patterns that avoid sharing overhead on LDV objects
  • Big object limitations and surfacing big object data to users
  • Archive versus purge versus backup in a data retention plan
  • Tiering active, warm, cold and expired data across storage options
  • Retention periods and purge criteria for regulated data
  • Selecting archive candidates and preserving record context
  • Big objects as an on-platform archive for historical records
  • External archive stores and on-demand access to archived records
  • Field history retention beyond the standard tracking window
  • Bulk API hard delete versus Recycle Bin soft delete for mass purges
  • Reducing file storage versus data storage consumption
  • Ongoing archiving to sustain performance as data volumes grow
  • Packaged archiving solutions versus custom-built archive pipelines
  • Virtualizing external data versus replicating it into Salesforce
  • Salesforce Connect adapter selection by source system
  • External object feature support compared with custom objects
  • Rate limits and query performance for external objects at high volume
  • Salesforce Connect versus request-reply callouts and UI mashups
  • Heroku Connect data proxy versus data replication
  • Source-to-target field mapping and org preparation before import
  • Staging-area profiling and cleansing versus post-load cleanup
  • Standardizing picklist, address and formatted values before load
  • External ID keys and upsert for repeatable, duplicate-safe loads
  • Validation rules and required fields as load-time quality controls
  • Matching and duplicate rules as a load-time quality gate
  • Preserving legacy audit fields and record ownership during migration
  • Test imports and post-load reconciliation of migrated data
  • Data Import Wizard versus Data Loader versus ETL tools for LDV loads
  • Bulk API versus SOAP and REST APIs for LDV migration loads
  • Bulk API 2.0 versus Bulk API 1.0 for migration jobs
  • Batch size tuning for load throughput, timeouts and retries
  • Insert, update and upsert choice for load speed
  • Loading lean: minimal data set and deferred relationships
  • Load sequencing and configuration kept in place during migration
  • Suspending triggers, validation rules and workflow during LDV loads
  • Deferring sharing calculation during LDV loads
  • Full copy sandbox load rehearsal and load-window planning
  • Data Export Service versus Data Loader for exporting org data
  • Data Export Service limits as a backup and recovery mechanism
  • Data Loader Export versus Export All for deleted and archived records
  • Data Loader export query scope and unsupported fields
  • Record visibility and protection of exported data
  • Bulk API versus SOAP and REST API for large data extracts
  • PK chunking versus filter-based chunking for very large extracts
  • Full, incremental, and partial backup strategies
  • Native export tools versus Salesforce Backup and AppExchange backup solutions

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform Data Architect studiers.

Go to Discord
  1. Platform Data Architect Checklist
  3. Data Modeling/Database Design

Role hierarchy design for data access and scale

Explainer

Learn More

Practice Question

Keep going

Next conceptSharing rules and public group design at scale

Checklist progress

0/156 (0%)

0 of 156 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform Data Architect studiers.

Go to Discord
Close
  1. Platform Data Architect Checklist
  3. Data Modeling/Database Design
Role hierarchy design for data access and scale

Explainer

Learn More

Practice Question

Keep going

Next conceptSharing rules and public group design at scale

Explainer

The role hierarchy is a tree of roles that opens up record access vertically: users in higher roles automatically get access to records owned by or shared with users below them. A good design models levels of data access, not the company org chart. It stays small and shallow so that sharing calculations stay fast as users and data grow.
Core information
  • The role hierarchy gives managers the same access as their subordinates, regardless of organization-wide defaults. For example, if Sales Manager sits above Sales Rep, Sales Managers can see every record that Sales Reps own or can reach through sharing rules, manual sharing, or other features, with no extra sharing rules needed.
More details and nuances
  • Grant Access Using Hierarchies can be turned off only for custom objects, in the organization-wide default settings, where it is checked by default. It can't be changed for standard objects. When it is off, users above the owner lose automatic access. Users with View All Records, Modify All Records, View All Data, or Modify All Data can still see the records.

Explainer

The role hierarchy is a tree of roles that opens up record access vertically: users in higher roles automatically get access to records owned by or shared with users below them. A good design models levels of data access, not the company org chart. It stays small and shallow so that sharing calculations stay fast as users and data grow.
Core information
  • The role hierarchy gives managers the same access as their subordinates, regardless of organization-wide defaults. For example, if Sales Manager sits above Sales Rep, Sales Managers can see every record that Sales Reps own or can reach through sharing rules, manual sharing, or other features, with no extra sharing rules needed.
More details and nuances
  • Grant Access Using Hierarchies can be turned off only for custom objects, in the organization-wide default settings, where it is checked by default. It can't be changed for standard objects. When it is off, users above the owner lose automatic access. Users with View All Records, Modify All Records, View All Data, or Modify All Data can still see the records.