Salesforce Data Management Intern

Sign up for a free Developer Edition org and build a data model with at least three related objects.

Create your own source data.

Build spreadsheets of at least eighty records with the imperfections real data carries: inconsistent capitalisation, varied date formats, missing values, extra spaces, phone numbers in several formats, and some rows referencing parents that do not exist.

Creating the mess deliberately is part of the exercise, since clean practice data teaches nothing about importing.

Plan before importing.

Map every source column to its target field, note type mismatches, decide what happens to blank values, and determine the import order, because child records cannot reference parents that are not yet there.

Import with the Data Import Wizard first.

Run it, capture the result, and examine every failed row to determine why it failed.

Fix the source and reimport, recording what you changed.

Then use Data Loader for a larger import, which is the tool used when volume grows.

Configure it, run an insert, and capture the success and error files it produces.

Handle relationships.

Import child records linked to the correct parents using external identifiers or lookup matching, and confirm the links are right rather than assuming they are.

Finally, verify the outcome.

Build reports proving record counts match expectations, relationships resolved, and no field silently truncated, then write what you would check before any future import.

Submit the source data, the mapping plan, both import attempts with error analysis, the relationship evidence, verification reports, and your pre-import checklist.

Duplicates make a CRM untrustworthy: two records for one customer mean two histories and two wrong answers.

Create the problem realistically.

Add records duplicating existing ones the way users actually do it, with name variations, abbreviations, different capitalisation, one with a typo, one with a different phone number, and one genuinely distinct record that merely looks similar.

The near miss matters, because merging two real customers is worse than leaving a duplicate.

Find them.

Build reports or use duplicate tools to identify likely duplicates, then produce a list classifying each pair as definitely the same, probably the same, or different.

State the evidence for each classification.

Configure prevention.

Set up matching rules and duplicate rules controlling what happens when a user creates a probable duplicate, deciding deliberately whether to block or warn and justifying the choice.

Prove it by attempting to create a duplicate and screenshotting the result.

Now merge carefully.

Before merging, document what each record holds that the other does not, since merging destroys data and the loss must be deliberate.

Merge your confirmed duplicates, choosing the master record consciously, and verify related records survived.

Leave the near miss alone and write why.

Then measure the outcome.

Report on record counts before and after, and write a note on how duplicates got in and what change would reduce them at source.

Submit the duplicate dataset, the classification list with evidence, rule configuration with prevention evidence, pre-merge documentation, merge verification, the near miss reasoning, and the root cause note.

Cleaning data once achieves nothing if the same problems return next month.

Define what quality means for your business.

For each object, state which fields must be populated for a record to be usable, what valid values look like, and which combinations are contradictory, such as a closed record with no resolution or a future date in a field that must be past.

Build prevention.

Implement validation rules enforcing your definitions, with error messages telling the user how to fix the problem and appearing next to the relevant field.

Set required fields at the layout level where appropriate, and explain the difference between a required field and a validation rule.

Test every rule.

Attempt to save records violating each one, screenshot the block, then confirm a legitimate record still saves, because over-tight validation that stops real work gets switched off entirely.

Now monitor the existing data.

Build reports surfacing records already failing your standards: missing required information, stale records, contradictory values.

Produce a quality scorecard showing the percentage of records meeting standard per object.

Then remediate.

Fix a portion of the failing records, using a mass update where appropriate, and report the scorecard again to show the improvement.

Consider the balance.

Write a note on the validation rule you considered but rejected as too restrictive, explaining the tradeoff between data quality and user burden.

Finally, write a monthly maintenance routine someone else could follow.

Submit the quality definitions, validation configuration with test evidence, the monitoring reports, before-and-after scorecards, the rejected rule with reasoning, and the maintenance routine.

The most damaging data incidents come from bulk operations run without a way back.

Define a realistic bulk change, such as recategorising records after a business change, reassigning a departing owner's records, or standardising inconsistent values across a field.

Back up first.

Export the affected records with their identifiers and current values using the data export tool or Data Loader, and store the file.

Write down exactly how you would use this file to restore the previous state, because an untested backup is not a backup.

Plan the change.

Write the steps, the records affected and their count, what will change, and what must remain untouched.

Identify the automation that will fire on these updates, since bulk changes triggering flows is how a simple update becomes an incident.

Test small.

Run the change on five records first, verify the outcome completely including whether automation fired as expected, and only then proceed.

Run the full change with Data Loader, capturing the success and error files, and investigate every error.

Now verify properly.

Confirm the intended records changed, confirm no unintended records changed, and confirm related data is intact.

Then test recovery for real.

Pick ten records, restore them to their original values from your backup, and prove the restore worked.

Record how long it took and what you would do differently restoring thousands.

Finally, write a runbook for bulk changes that another person could follow.

Submit the change definition, the backup file and restore method, the plan with automation assessment, small batch evidence, full run results, verification, the tested recovery, and the runbook.