Salesforce Flow Automation Intern

Sign up for a free Developer Edition org and build a simple data model with at least two related objects and twenty records.

Learn the elements by using them.

Build a flow using an assignment, a decision, a get records, an update records, and a loop, documenting what each does with a screenshot.

Now confront trigger timing, which is the distinction that separates competent Flow work from guesswork.

Build a flow updating a field on the record that triggered it, first configured as before-save, then the same logic as after-save.

Record the behaviour difference, which executes faster, and why, then write the rule you would apply when choosing between them.

Test entry conditions.

Build a flow with entry conditions and prove it does not run on records that fail them, because a flow running on every record update is a performance problem that only appears at scale.

Next, handle related records.

Build a flow reading a parent record and updating children, or the reverse, using a get and a loop.

Run it on a parent with several children and one with none, confirming the empty case does not error.

Finally, use the debug tool on three runs and capture what it reveals internally.

Submit the element exercises, the before-save versus after-save comparison with your rule, entry condition evidence, the related record flow including the empty case, and the debug captures.

Screen flows replace training with structure, guiding a user through a process rather than presenting an empty form.

Choose a process with real sequence, such as logging an enquiry, booking an appointment, or running a qualification call where later questions depend on earlier answers.

Design the screens first.

Map each screen, the fields on it, and the logic deciding what comes next.

Keep the number of fields per screen low, since a screen flow reproducing one long form has achieved nothing.

Build it.

Create the screen flow with multiple screens, input components, and at least one decision that branches the path.

Make the branching real so different answers lead to genuinely different screens.

Add validation at entry.

Configure input validation on at least three fields with error text telling the user how to fix the problem rather than only stating it is wrong.

Create and link records.

Have the flow create or update records at the end, confirm the data lands correctly, and handle the case where a matching record already exists rather than creating a duplicate.

Now test with a real person.

Have someone unfamiliar complete the flow while you watch without helping.

Record every hesitation and wrong turn, treat each as a design fault, and fix the worst three.

Finally, deploy it to a page or action so a user can actually launch it, and screenshot the entry point.

Submit the screen map, the flow build, validation evidence, record creation evidence including the duplicate case, the usability test with fixes, and the deployment screenshot.

Some problems are only visible over time, such as records going stale or follow-ups never happening, and these need scheduled rather than triggered automation.

Find the invisible work.

From your data, identify three conditions nobody would notice until it hurt: records untouched for weeks, dates passed without action, required information never completed.

Write why each matters.

Build a scheduled flow handling the most valuable one.

Configure the schedule and the record filter, and process the matching records with appropriate actions.

Generate enough records so the run has real volume.

Run it and verify.

Execute the scheduled flow, capture the result, and confirm it touched exactly the records intended and nothing else.

Then check what happens on a second run, because automation acting twice on the same record is a common and damaging bug.

Make it idempotent.

Add a mechanism, such as a stamp field or tighter filter, ensuring a record is not processed repeatedly, and prove the second run is now clean.

Consider volume.

Research the limits on scheduled flow runs and write what would happen if your filter matched fifty thousand records instead of fifty, and how you would handle that.

Then build monitoring.

Decide how someone would know this flow failed when nobody was watching, implement it, and explain your approach.

Submit the invisible work analysis, the scheduled flow configuration, first and second run evidence, the idempotency fix, the volume analysis, and the monitoring approach.

Automation nobody understands becomes automation nobody dares change, and this task produces the artefacts preventing that.

Inventory everything.

List every flow in your org with its name, type, trigger, purpose, and what it modifies.

Identify any two flows touching the same object and assess whether they could conflict or run in an order that produces a wrong result.

Now test adversarially.

For each flow, construct the case designed to break it: missing related records, a record failing entry conditions by one value, bulk updates of two hundred records at once, and a user without permission to the object.

Record what happens in every case, and fix anything that errors ungracefully.

Find the order problem.

Deliberately create a scenario where two of your flows both fire and show the outcome, then state whether the result depends on execution order and how you would control it.

Check the limits.

Research flow element limits and write what your most complex flow consumes per run and how close to a ceiling it sits.

Write the documentation.

For each flow produce a one page record covering purpose, trigger and entry conditions, step by step logic, what it modifies, known limitations, and what to verify before changing it.

Write it for someone who has never seen your org.

Finally, write the honest limitation note naming the one scenario where your automation still produces an unwanted result and what you would build to guard it.

Submit the inventory with conflict assessment, adversarial test results with fixes, the ordering experiment, the limits analysis, the per-flow documentation, and the limitation note.