Salesforce Platform Data Architect

Each modeling choice has a cost somewhere else. You decide between standard and custom objects, choose relationship types and field types, and use external IDs and record types where the scenario needs them.

• Standard objects or custom objects
• Lookup, master-detail and many-to-many relationships
• Self, hierarchical and polymorphic relationships
• Field types and what they cost in storage and queries
• External IDs and unique keys
• Record types and picklist design

You build A physical data model with each relationship and field type justified.

A relationship type changes sharing, reporting, deletion and limits. You trace those effects before building, so a model that looks tidy does not break access, roll-ups or automation later.

• Master-detail effects on ownership and sharing
• Roll-up limits and reporting consequences
• Cascade delete and orphan records
• Query relationship limits
• Effects on automation and integrations
• Reviewing a model against its side effects

You build A review of a model that lists each design choice and its side effects.

Bad data is cheaper to prevent than to fix. You set quality rules at entry with validation, duplicate management and controlled values, and measure quality so decay is visible before users stop trusting the org.

• Dimensions of data quality
• Validation rules and required fields
• Duplicate rules and matching rules
• Controlled picklists and standardized values
• Enrichment from outside sources
• Measuring quality with reports and scorecards

You build A data quality plan with entry rules and a scorecard.

Data has to be stored, found and recovered. You work out storage use and limits, how deleted and historical data behave, and how backup and restore fit a customer’s needs.

• Data storage and file storage limits
• Recycle bin, soft delete and hard delete
• Field history and audit retention
• Backup and restore strategies
• Making data accessible: views, search and reports
• Sandbox data and test data management

You build A storage and recovery plan for one org with a growth forecast.

At millions of records, a design that was fine becomes slow. You make queries selective, apply indexes and skinny tables, avoid data skew, and keep reports and list views working at scale.

• What makes a query selective
• Standard and custom indexes
• Skinny tables and when to request one
• Ownership and lookup skew
• Sharing recalculation at volume
• Reports and list views at volume

You build A tuning plan for a high-volume object with query and index changes.

Not all data needs to sit in Salesforce. You decide what to archive, purge or leave in place and read through, weighing the cost, speed and compliance effects of each option.

• Retention rules that decide what ages out
• Archiving to big objects
• Archiving to external storage
• Purging safely and in bulk
• Data virtualization with external objects
• Choosing between copy, archive and virtualize

You build A lifecycle plan that sends each data set to keep, archive, purge or virtualize.

A migration succeeds or fails on quality and sequence. You stage and cleanse data, load parents before children with external IDs, and speed up very large loads without causing lock errors or corrupting relationships.

• Staging, mapping and transforming source data
• Load order and relationship resolution
• Choosing among import tools by volume
• Parallel and serial loading and lock contention
• Deferring sharing and automation during loads
• Reconciling counts and values after a load
• Rollback and rerun strategies

You build A migration runbook for a large load with checks at every stage.

Getting data out is a design problem too. You choose export methods for the volume, handle large extracts without hitting limits, and keep extracts secure and consistent while the org keeps changing.

• Export options and what each includes
• Large extracts and PK chunking
• API limits and extract scheduling
• Consistency while data changes
• Securing exported data
• Extracts for reporting and for backup

You build An extract design for a large object with limits and security handled.

Governance gives data an owner and a rulebook. You define roles, policies and classification, apply privacy and retention duties, and set up the audit trail that proves the rules are followed.

• Governance roles: owners, stewards and custodians
• Data classification and sensitivity
• Privacy duties such as GDPR consent and erasure
• Retention and deletion policies
• A data dictionary and metadata standards
• Auditing and reporting on compliance

You build A governance charter with roles, policies and an audit routine.

When several systems hold the same customer, someone must decide which value wins. You compare hub styles, match and merge records, define survivorship rules and publish one golden record back to the systems that need it.

• Why master data fragments across systems
• MDM hub styles: registry, consolidation, coexistence
• Matching and merging records
• Survivorship: which attribute wins
• Harmonizing formats and reference data
• Publishing the golden record to other systems

You build A golden record design with matching and survivorship rules for a customer domain.

Take a scenario with many systems and heavy volumes and design the data architecture: model, quality, scale, migration, governance and master data. You defend the design against the questions a client would ask.

• Reading the scenario for data risks
• Designing the model and the scale plan
• Planning migration and master data
• Setting governance and quality controls
• Presenting and defending the design

You build A complete data architecture for one scenario, with its migration and governance plans.