AEP common mistakes
AEP · Understand the traps and how to avoid them.
Treating a record type as a table and expecting record fields to store data directly, instead of recognizing that a record type is a view over a data source (a database table, a web service, a process-backed entity, or a service-backed entity).
Candidates with relational-database backgrounds conflate the record type with the underlying table, so they misjudge which fields are writable, how relationships work, and where data actually lives.
What to do instead
For every record type, explicitly identify its data source type first, then reason about field mapping and write behavior from that source. Memorize that relationships are defined between record types and are realized through the underlying data source.
Designing a one-to-many relationship without a source of cardinality, then being surprised that a record can link to only one related record or that queries return unexpected results.
Candidates sketch relationships as plain field references and skip deciding which side holds the foreign key and whether the relationship is one-to-many or many-to-many.
What to do instead
Before building, state the cardinality in words ('one customer has many orders'), confirm which record type owns the reference, and verify by testing a query that returns multiple related records from the 'one' side.
Assuming a process variable and a process parameter are interchangeable, or expecting a process variable to be visible to a subprocess without passing it in.
Candidates learn the process model visually and treat all variables as globally scoped, missing that subprocesses receive values through parameters and inputs.
What to do instead
Map variable scope deliberately: process variables live per instance, parameters define the subprocess interface. When calling a subprocess, list the input and output mappings and confirm each variable used inside is either local, a parameter, or inherited as documented.
Building a multi-step user flow as a single giant form with conditional visibility instead of chaining task forms or using a wizard-style pattern, then failing questions about how data is saved between steps.
Candidates optimize for fewer objects and do not internalize that each user input task saves data at its completion, so intermediate state handling is misunderstood.
What to do instead
Practice decomposing a flow into sequential user input tasks and know exactly what is persisted when each task completes. When a question asks about partial saves, reason from task boundaries rather than from UI visibility rules.
Putting business logic in the interface layer (saveInto chains, visibility expressions, button logic) when the logic must be enforced regardless of entry point, and then answering questions as if the UI rule were authoritative.
The interface is where candidates first see the requirement, so they implement it where it is visible rather than where it is enforceable.
What to do instead
Ask 'what happens if this data arrives via integration or a process instead of this form?' If the rule must always hold, place it in the process or the data layer and treat the interface rule as presentation only.
Confusing an integration's connected system, integration object, and the process node that calls it, and therefore misidentifying where authentication, error handling, and retry behavior are configured.
These are three distinct configuration surfaces, and candidates collapse them into one mental object because they appear together in the designer.
What to do instead
Draw the three layers for each integration: connected system (base URL and authentication), integration (endpoint, request/response mapping), and caller (process node or expression). Assign each exam question's concern to the correct layer before choosing an answer.
Treating a group as equivalent to a role and granting object security directly to individuals or ad-hoc groups instead of through a designed group structure.
Both groups and roles appear in permission dialogs, so candidates assume they serve the same purpose and skip designing the group hierarchy.
What to do instead
Learn the distinct purpose of groups (identity and membership management, often synced from a directory) versus roles (a named set of permissions applied to objects). Design group structure first, then map roles to groups, and never grant to individual users in a production design.
Assuming an administrator or system-level user automatically sees all record data, ignoring record-level security and field-level visibility.
Candidates generalize from object-level permissions and forget that row-level and field-level rules can restrict even privileged users depending on configuration.
What to do instead
For any data-access question, check all three layers in order: object security, record-level security, and field-level security. State which layer the question is testing before answering.
Deploying an application package without accounting for dependent objects, then discovering the target environment is missing record types, groups, or connected system references.
Candidates focus on the objects they built and assume the deployment tool resolves everything, rather than reasoning about the dependency graph and environment-specific configuration.
What to do instead
Before any deployment question, enumerate dependencies: objects the app references, groups that must pre-exist, and connected systems that differ per environment. Verify the target environment has those prerequisites and that environment-specific values are reconfigured after import.
Skipping expression-level and process-path testing in favor of only clicking through the happy path in the interface, then failing questions about rule evaluation order and null handling.
Manual happy-path testing feels sufficient and does not surface edge cases like empty lists, null values, or alternative process branches.
What to do instead
For each expression or decision, test null, empty list, and boundary inputs explicitly, and trace every outgoing path of a process node. Know the platform's null-propagation behavior in expressions and design tests that exercise each branch.