Build Custom Screens with Data, Workflow Actions, and Document Workspaces

Choose the simplest suitable surface

RAPTIX Applications can hold several kinds of working surface:

A Custom Screen is not required merely to place documents inside an application. Start with a document-only workspace when the job is filing, sharing, reviewing, and following process documents; add a page only when users need a purpose-built interface.

Connect a Custom Screen to data

In App Builder, use supported queries, page logic objects, and widget events to retrieve and present only the data the page needs.

1. Define the query or approved data source.
2. Bind the result to a table, form, text, chart, or another supported widget.
3. Keep reusable transformations and page behaviour in the page's supported logic object rather than duplicating the same expression across widgets.
4. Connect a widget event—such as a button click, selection, or form submission—to the intended query or action.
5. Test empty, loading, success, permission-denied, and failure states.

The editor controls available to you depend on the current App Builder version and plan. Do not paste secrets into page code or use a query to bypass RAPTIX access rules.

Start a Workflow from a button

A Workflow button should make the intended process and inputs clear.

1. Choose an active Workflow that supports the page's trigger type.
2. Map page or selected-row values to its required inputs.
3. Label the button with the business action, such as Start supplier review, rather than a generic Submit.
4. Add confirmation when the click creates consequential work.
5. Show the accepted instance reference or an actionable error after the request.

One click should create one intended instance. Disable repeated submission while a start request is in progress, and let the user check the receipt before retrying.

Complete a task action from a screen

TaskActions connect a Custom Screen to an assigned human task. Depending on the task design, a page can display task context and offer domain-specific actions such as Approve, Request changes, or Reject.

The action must respect the same requirements as the task manager:

• the signed-in person must still be an eligible assignee;
• required comments, fields, files, or row decisions must be complete;
• the task must still be pending; and
• the action must use the current task and instance context.

If another eligible participant acts first on a shared task, refresh the page and follow the recorded outcome instead of submitting a second decision.

Use approval tables

An approval table can present item-level decisions inside a Custom Screen. Configure the displayed rows, allowed decisions, required comments, and mapping back to the Workflow. Advanced per-item or batch behaviour can require an eligible plan.

Before publishing, test:

• one approved and one rejected row;
• required comments or supporting files;
• partial completion and validation messages;
• a stale task that has already been completed; and
• the Workflow's summary and retry path.

Use a document-only workspace

Create or choose an application container, then use its Documents area to organise folders, permissions, process files, and activity. This gives the team a shared business context without exposing an empty or unnecessary App Builder page.

You can later attach a Workflow form or Custom Screen without moving the document history. Document permissions remain separate from permission to open an application page.

Publish and verify access

1. Preview the page with realistic data.
2. Confirm the application and page grants for the intended users or roles.
3. Confirm the Workflow, task, and document permissions separately.
4. Publish the page.
5. Test as a normal member, not only as an administrator.
6. Test the Arabic and English labels that the page supplies.

Opening the application does not automatically grant access to every query result, Workflow, task, document, or assistant embedded in it.

Troubleshooting