Platform App Builder common mistakes
Platform App Builder · Understand the traps and how to avoid them.
Selecting a Roll-Up Summary field to total child records when the two objects are joined by a lookup relationship, then finding the field type unavailable or the roll-up returning nothing.
Roll-Up Summary is memorized as 'the way to aggregate children', and candidates skip the step of confirming the relationship type before choosing the field type.
What to do instead
Before picking any aggregation tool, ask what the relationship is. Lookup = no Roll-Up Summary; use a record-triggered flow (or a scheduled flow) to recalculate the parent, or convert the lookup to master-detail if the data model allows it.
Writing a formula field on the parent object that references a numeric field on a child object, e.g. trying to display a child's Amount on the Account.
Cross-object formulas feel symmetric, so candidates assume 'reference a field on a related record' works in both directions.
What to do instead
Remember cross-object formulas only travel toward the one side (child can read parent fields). To surface child data on the parent you need a Roll-Up Summary over master-detail, or a flow that writes the computed value onto a parent field.
Converting an existing lookup relationship to master-detail without checking that every record already has a value in the lookup field, or proposing a third master-detail relationship on the same object.
The conversion is treated as a simple metadata toggle, and the constraints (populated field, two-master-detail maximum) are not top-of-mind under time pressure.
What to do instead
Check the constraint first: an object may have at most two master-detail relationships, and the lookup field must be populated on all records before conversion. If either fails, keep the lookup and solve with a flow, or restructure the model.
Assuming that a time-dependent workflow action queued for three days out will still fire even if the record stops meeting the rule criteria in the meantime.
Candidates picture the action as already 'scheduled' and therefore committed, rather than as conditionally re-evaluated.
What to do instead
Treat time-dependent actions as conditional on the criteria remaining true: if the record no longer meets the rule criteria, the pending action is removed. If the business needs the action regardless, use a scheduled flow with explicit logic rather than a time-dependent workflow action.
Designing a record-triggered flow to react when a record is deleted, then discovering no delete trigger exists in the configuration.
The trigger options (create, update, create-or-update) are scanned quickly and 'delete' is assumed to be in the same list as it is for other platforms.
What to do instead
Confirm the platform's trigger set up front: record-triggered flows cover create and update only. For delete-time logic you must use an Apex trigger, or re-architect so the need is met without a delete event.
Placing a Create Records, Send Email, or Submit for Approval action inside a before-save (fast field update) flow and expecting it to run.
Before-save and after-save flows look like the same canvas with a different timing radio button, so their differing action capabilities get overlooked.
What to do instead
Match the flow type to the work: before-save flows are limited to updating the triggering record's own fields (no DML on other records, no emails). Anything beyond that belongs in an after-save flow.
Answering that a sharing rule (or an organization-wide default of Private) can be configured to take access away from a group of users who already have it.
Sharing rules and OWDs are grouped mentally as 'the sharing model', so candidates assume the model both grants and revokes access.
What to do instead
State the rule explicitly in your head: sharing mechanisms only ever open up access; they never reduce it. To restrict users who already have access, you must change the object permission on the profile or permission set, or adjust role hierarchy/OWD, not add a sharing rule.
Proposing a permission set as the way to hide a field or remove an object permission that a profile already grants.
Permission sets and profiles both appear on the user's access list, so they are treated as equivalent levers that can add or subtract.
What to do instead
Treat permission sets as additive only. To remove access you must edit the profile (or the permission set that granted it); a permission set can grant a permission but can never override one that is already granted.
Making a field required only by checking 'Required' on the page layout, then expecting Data Loader or an API insert to fail when the field is blank.
The page layout Required checkbox is visually the most obvious 'make it mandatory' control and its enforcement scope is easy to overestimate.
What to do instead
Recall that page-layout required only applies to the UI. If the field must be mandatory for all entry paths, create a validation rule (or set field-level security as needed) and verify it fires on API and bulk loads too.
Assuming a change set will carry production data, or will remove a component that no longer exists in the source org, and planning a deployment around it.
Change sets are the default mental model for 'moving things between orgs', and candidates conflate metadata movement with data movement and with deletion.
What to do instead
Scope change sets correctly: metadata only, additive only. Move data with Data Loader or a data deployment tool, and delete components through the Metadata API with a destructiveChanges manifest or the appropriate deployment tool.