Customization and SuiteBuilder
This domain tests what you can build without code and how it behaves at runtime: custom fields, custom records, forms, and SuiteFlow. Questions ask where a field should live, how it gets its value, and why it does not appear.
Building blocks
- Custom fields attach to entities, transactions (body or line), items, or custom records. Store Value on saves a static copy; off computes dynamically.
- Sourcing pulls a value from a related record listed in Source List; Filter Using narrows the source; the field recalculates when the source field is set.
- Custom record types define their own entries, fields, permissions, and parent links; they are not transactions.
- Forms control layout per role: preferred form, subtabs, mandatory fields. A field existing does not mean it appears on a form.
- SuiteFlow workflows use states, transitions, conditions, and actions, and run on record create or edit.
Worked example
A line-level custom field "Vendor Code" must default from the item. Set Source List to Item, Source From to the item's vendor-code field, and Filter Using to the same item field. Because the field sits on the line, it fires when the item is chosen. Leave Store Value off if it must always reflect the current item; turn it on if it must be frozen for reporting. Reasoning: sourcing only works across records named in Source List.
Traps that cost marks
- Storing a value that should stay dynamic, freezing stale data.
- Deploying a workflow without releasing it, or expecting it to run on display rather than on save.
- Confusing custom record permissions with role-level permissions.
- Adding a field to the record but forgetting to place it on the form layout.