Salesforce Training and Documentation Intern

Sign up for a free Developer Edition org and build a CRM with at least three objects, relationships, validation rules, two automations, and three user profiles.

You must document something real, so build it first.

Document the system as built, for a technical reader.

Record each object and its purpose, the fields and what they are for, the relationships, the validation rules and what they prevent, the automations and when they fire, and the profiles and their access.

This is reference material rather than instruction.

Now analyse the audiences, because one document for everyone serves nobody.

For each of your three user types plus a future administrator, write what they need to accomplish, what they already know, how much time they will give to reading, when they will look something up, and what happens if they get it wrong.

Identify what each audience does not need.

Deciding what to leave out is most of technical writing, and a guide containing everything gets abandoned.

Then map content to audience.

Produce a plan listing the documents you will create, who each is for, what it covers, and roughly how long it will be.

Test an assumption.

Ask someone what they would want to know first about a system like this, and compare it with what you assumed, recording the difference.

Finally, write the thing about your own system that is hardest to explain, and why.

Submit the technical system documentation, the audience analysis with exclusions, the content plan, the assumption test, and the hard-to-explain note.

Write a guide for each of your three user types, organised around the tasks that user performs rather than around the screens the system has, since users arrive with a task and not with curiosity about your menu structure.

For each guide, identify the six to eight tasks that role genuinely does, then write each as numbered steps a person can follow while working.

Include what they see at each step, what to do when the expected thing does not appear, and what the validation error messages mean in plain language.

Use screenshots deliberately.

Include one only where it removes ambiguity words cannot, annotate it, and keep it current, because a guide full of decorative screenshots is unmaintainable.

Write for the actual reading situation.

Keep sentences short, put the action first, and make every section findable by its heading alone, since nobody reads a user guide from the beginning.

Now test each guide properly.

Give it to someone unfamiliar with Salesforce, ask them to complete the tasks using only the guide, and do not help.

Record every hesitation, wrong turn, and question, treating each as a defect in your writing rather than in their reading.

Revise based on what you observed.

Fix at least five specific problems per guide and record what you changed and why.

Retest the worst task with a different person to confirm the fix.

Finally, write what the test revealed about your own writing habits.

Submit the three guides, the screenshot decisions, per-tester observation logs, the revisions with reasoning, the retest, and the self-assessment.

Users resent changes they were not told about, and release communication is a distinct skill from documentation.

Make three real changes to your org: one adding capability, one restricting something previously permitted, and one changing how an existing task is done.

The restriction matters most, since that is the change that generates complaints.

Write the release notes.

For each change, record what changed, why, who is affected, what they must do differently, and when it takes effect.

Lead with the user impact rather than the configuration detail.

Now write the same release for three audiences.

Produce a short announcement for end users focused entirely on what they must do differently, a summary for managers covering the business reason and the impact on their team, and a technical record for a future administrator covering exactly what was configured and how to reverse it.

Handle the restriction carefully.

Write the communication for the change that takes something away, explaining the reason without being defensive and stating what the user should do when they hit the new limit.

Build the migration note for anything users must do, such as finishing work in the old way before a cutoff.

Then test comprehension.

Give the user announcement to someone and ask what they think they must do differently.

Where they get it wrong, revise it and record the change.

Add the version history, a running record of changes someone could read in six months to understand how the org reached its current state.

Finally, write what you would tell users nothing about, and why that is justified.

Submit the three changes, the release notes, all three audience versions, the restriction communication, the migration note, the comprehension test with revision, the version history, and the silence justification.

Design the training.

For one user role, plan a session of at most forty five minutes, stating the three things a participant must be able to do afterwards.

Three outcomes is the realistic limit, and a session covering everything achieves none.

Build the materials: a session outline with timings, the demonstration script of what you will show in what order, two or three hands-on exercises using your org, and a one page quick reference they keep afterwards.

Prepare for the questions.

Write the eight questions participants are most likely to ask, including the two you would struggle with, and your answers.

Now deliver it to at least two people, in person or over a call.

Follow your timings and note where you ran over, where attention dropped, and which exercise caused difficulty.

Measure whether it worked.

After the session, ask each participant to perform the three outcome tasks without help, and record who could.

This is the only honest measure of a training session, rather than whether people enjoyed it.

Revise the material based on what failed, making at least four specific changes.

Then build the administrator handover, which is the document that matters most when you leave.

Cover what the org contains, the decisions taken and why, the automations and what to check before changing them, the known limitations, the things that will break if touched, and what you would do next.

Write it for someone who has never seen this org.

Test it by having someone use the handover to find the answer to three questions about your org.

Finally, write the one thing about this org only you know, and get it written down.

Submit the session plan and materials, the anticipated questions, delivery observations, the outcome measurement, the four revisions, the administrator handover, its findability test, and the undocumented knowledge note.