Workspace page event flow
Data is retrieved once, bound to components, and passed through explicit events. Protected updates remain server-side.
Build from page purpose
Start by defining what the user must accomplish on the page. Select the correct page template and variant, then arrange components around that task instead of adding components first.
- Page and route
- Audience and conditions
- Layout and components
- Data resources
- Events and actions
Connect data to presentation
Use data resources to retrieve records and bind their outputs to component properties. Repeaters are useful when the same card or row must render for each returned record.
Handle user actions
Component events can update client state, open a modal, navigate to a record or execute a declarative action. Test the action in the correct workspace and user context, including access controls.
Implementation steps
Follow these steps in a personal developer or sub-production instance. Validate backend names and choice values before using the solution in production.
Create the workspace and experience
WHERE: App Engine Studio and UI BuilderDefine the audience, landing page and navigation before adding components.
Create list and record pages
WHERE: UI Builder pages and routesUse a list page for Problem records and a record page for a selected sys_id.
Configure the data resource
WHERE: Data resourcesRetrieve number, short description, description and state. Apply the user-visible filter and access controls.
Bind a repeater or list
WHERE: Component propertiesBind each row to the data output. Use sys_id for navigation and number only as display text.
Add the record action
WHERE: Declarative ActionsCreate a declarative action shown only when state is New. Execute a secured server update to Assess.
Show user feedback
WHERE: Action event handlerReturn success or failure and show an alert containing the current logged-in user's display name.
Test page variants
WHERE: UI Builder preview and ATFTest desktop, mobile, empty data, access denied and invalid route scenarios.
Server-side Problem state update
Keep authorization and state validation on the server. Verify the state choice values because they may differ by process or customization.
function moveProblemToAssess(problemId) {
var problem = new GlideRecordSecure('problem');
if (!problem.get(problemId))
return {ok: false, message: 'Problem not found'};
if (!problem.canWrite())
return {ok: false, message: 'You cannot update this problem'};
if (problem.state != '1')
return {ok: false, message: 'Only New problems can move to Assess'};
problem.state = '2'; // Verify choice values in your instance.
problem.update();
return {ok: true, message: 'Problem moved to Assess'};
}How to test it
- 1Problem number opens the correct sys_id
- 2Unauthorized user cannot read or update
- 3Action appears only in New state
- 4Successful action refreshes the record
- 5Empty list shows an explanatory state
- 6Invalid route does not display stale data
Common mistakes
- Building URLs from problem numbers
- Using client state as permanent storage
- Protecting the button but not the server action
- Ignoring loading and empty states
- Testing only as admin
Can you explain this solution under pressure?
Practice real scenarios covering this topic, architecture decisions, troubleshooting and security.
Explore more implementation guides or request the next topic.