> For the complete documentation index, see [llms.txt](https://docs.rewst.help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rewst.help/rewst-documentation/documentation/apps/how-to-create-an-app-ask-the-rewst-agent.md).

# How to create an app: Ask the Rewst Agent

Creating an app with Rewst involves considering your use case, choosing the correct components, and assembling all the needed pieces in the background to achieve your goals. The best way to do this is to ask the [Rewst Agent](/rewst-documentation/documentation/rewst-agent.md) to create your app for you. In Rewst Classic, setting up your app required the manual creation of a workflow and the linking of workflow to app with Jinja. Ask the Rewst Agent to create your app and watch it do all that work for you, no coding required on your part.

{% hint style="success" %}
The Rewst Agent will ask you if an [integration](/rewst-documentation/documentation/integrations.md) is missing, but the fastest way to set up your app is to have the needed integrations set up within Rewst before asking it to build your app. 
{% endhint %}

### Craft prompts for building an app with the Rewst Agent

The agent builds better apps when your prompt answers seven things. A well-written paragraph should contain answers to the following questions:

<table data-search="false"><thead><tr><th>Question</th><th>Why it matters</th></tr></thead><tbody><tr><td>Who is the audience?</td><td><ul><li>An internal tech dashboard and a client-facing portal get different surfaces</li><li>Explain who else sees the app - internal only versus shared with a client</li></ul></td></tr><tr><td>What is the one decision or job the app should achieve?</td><td><ul><li>Drives what lands in the first viewport vs. what's a drill-down</li></ul></td></tr><tr><td>Where does the data come from?</td><td><ul><li>A named integration, a datastore collection, an existing workflow, or static sample</li><li>Indicate whether actions may run live against real systems</li></ul></td></tr><tr><td>What must the top of the page answer at a glance?</td><td><ul><li>Becomes the KPI row or header</li></ul></td></tr><tr><td>What is the main list or record set, and which columns should be used?</td><td><ul><li>Becomes the table</li></ul></td></tr><tr><td>What can a user can do - open detail, filter, submit, re-run, export, etc.?</td><td><ul><li>Becomes interactions, slideouts, forms, workflow actions</li></ul></td></tr><tr><td>Should the app use standard Rewst components or custom-branded design?</td><td><ul><li>Standard or native app design is the default and cheaper for your token cost </li><li>Custom-branded design is hand-authored HTML/CSS for branded and premium appearance</li></ul></td></tr></tbody></table>

#### Example prompts

Click on any of the below examples to expand and view its full prompt.

<details>

<summary><strong>Service desk triage command center - unbranded</strong></summary>

Build an internal App Builder app called Service Desk Triage for our helpdesk dispatchers. The job is to decide, in under 30 seconds each morning, which tickets need attention right now. Pull open tickets from our PSA. Top of the page: KPI tiles for open tickets, tickets breaching SLA in the next 4 hours, unassigned tickets, and tickets untouched for 3+ days. Below that, a bar chart of open tickets by board and a donut of tickets by priority. Then a searchable, sortable table of open tickets with columns Ticket #, Client, Summary, Priority (colored badge), Assigned Tech, Age in hours, and Last Updated — default sort oldest-updated first. Add a client filter in the page header that re-queries the data. Clicking a row opens a slideout with the full ticket detail and its recent notes. Use standard Rewst components, not custom CSS.

</details>

<details>

<summary><strong>New-user onboarding request portal - unbranded and workflow action</strong></summary>

Build an App Builder app called New User Requests that our client account managers use to request a new user account without emailing the helpdesk. One page. Top section is a form: Client (dropdown from our PSA companies), First Name, Last Name, Job Title, Manager Email, Start Date, License Type (dropdown: choose from the license SKUs we actually have available), and Copy Permissions From (optional email). Submitting the form calls a workflow that writes the request to a Datastore collection and returns the new request ID, then shows a success message with that ID and clears the form. Below the form, a table of the last 50 requests with Requested By, Client, User, Start Date, Status badge, and Submitted date, refreshed after each submit. Don't provision anything yet. This is intake only. Create the backing workflow too, and test it in preview before going live.

</details>

<details>

<summary><strong>Microsoft 365 license and seat spend dashboard - unbranded</strong></summary>

Build an App Builder app called License Optimization for our vCIOs so they can walk into a client meeting and immediately see wasted spend. Data comes from Microsoft Graph across our customer tenants. Header KPIs: total assigned seats, total unassigned/available seats, estimated monthly spend on unassigned seats, and count of licensed users with no sign-in in 90 days. A horizontal bar chart of unassigned seats by SKU. A table of licensed-but-inactive users with Client, Display Name, UPN, Assigned SKUs, Last Sign-In, and Days Inactive, sortable by Days Inactive descending. Add a client selector in the page header that filters the whole page including the KPIs. Row click opens a slideout with that user's full license and sign-in detail. Read-only, no license changes from this app.

</details>

<details>

<summary><strong>Client health QBR one-pager - custom-branded</strong></summary>

Build a client-facing App Builder app called Client Health Review that we screen-share during quarterly reviews, so it needs to look polished and on-brand. Use a custom designed visual surface, not stock components. Dark header with the client name and review period, then a hero row of four large stat cards: tickets closed this quarter, average first-response time, SLA attainment percentage, and endpoints fully patched. Below that, a line chart of ticket volume by month for the last 12 months and a stacked bar of tickets by category. Then a clean section listing the top 5 recurring issues with counts, and a section listing endpoints needing attention. A client and quarter selector at the top drives everything. All data read-only from our PSA and RMM. No internal cost data or tech names anywhere on the page.

</details>

<details>

<summary><strong>Patch compliance and endpoint risk - unbranded</strong></summary>

Build an internal app called Patch Compliance for our NOC team. Primary decision: which endpoints do we chase today. Data from our RMM. KPI row: total endpoints, endpoints compliant, endpoints missing critical patches, endpoints offline 7+ days. A progress-style table of clients with Client, Endpoint Count, Compliance % as a progress bar, Critical Missing, and Last Sync. A second table below of the worst 100 individual endpoints with Client, Hostname, OS, Missing Critical Count, Missing Total, Last Reboot, and Last Check-In. Filters in the header for client and OS family. Row click opens a slideout showing the specific missing patches for that endpoint, plus a "Request patch run" button that submits a Datastore-tracked request rather than triggering anything directly.

</details>

<details>

<summary><strong>Automation operations dashboard - unbranded, no integration needed</strong></summary>

Build an internal app called Automation Health so our automation team can see whether our Rewst automations are actually working. Back it with a workflow that reads our workflow run history. KPIs: runs in the last 24 hours, failed runs in the last 24 hours, success rate percentage, and average duration. A line chart of runs per day for 30 days split by succeeded vs. failed. A table of the most recent failed runs with Workflow Name, Started, Duration, Failing Step, and Error Message, newest first. A time-range selector in the header (24h / 7d / 30d) that re-runs the query. Row click opens a slideout with the full error detail for that run.

</details>

<details>

<summary><strong>Offboarding approval queue with actions - unbranded and live workflow</strong></summary>

Build an app called Offboarding Queue for our service desk leads. It's a work queue, not a report. Read pending offboarding requests from a Datastore collection. Header shows counts of pending, approved today, and rejected. The main surface is a table of pending requests with Client, Departing User, Requested By, Last Day, Data Owner, and Requested date. Clicking a row opens a slideout with the full request plus three buttons: Approve, Reject with reason (text field required), and Hold. Each button calls a workflow that updates the record status and stamps who acted and when, then refreshes the table and closes the slideout. Show a clear error state in the slideout if the workflow fails instead of silently closing.

</details>

<details>

<summary><strong>Hardware warranty and asset refresh planner - unbranded</strong></summary>

Build an app called Asset Refresh Planner for our account managers to plan hardware budgets. Data from our RMM asset inventory. KPIs: assets out of warranty, warranties expiring in 90 days, assets older than 5 years, and total assets. A bar chart of assets by purchase year. A table with Client, Hostname, Model, Serial, Purchase Date, Warranty End, Age in Years, and a Status badge (In Warranty / Expiring Soon / Expired). Filter by client in the header, plus a search box on the table. Default sort by Warranty End ascending. Read-only.

</details>

<details>

<summary><strong>Embedded assistant page</strong></summary>

Add a page called Ask Automation to my existing Automation Health app. It should be a single full-height embedded Rewst Agent chat using our existing automation-support agent, with a short heading explaining that the team can ask it about failed runs and workflow behavior. Internal users only.

</details>

#### Reusable prompt fragments

Here are some examples of what you could drop into any of the above prompts to refine your request for the Rewst Agent.

* Filter that actually changes the data: "Put a Client selector in the page header; selecting a client re-runs the backing workflow with that client as an input so the KPIs and the table both update."
* Row-click detail: "Clicking a table row opens a slideout showing the full record, with the raw fields grouped under labeled sections."
* Reuse existing work: "Use my existing `get-open-tickets` workflow as the data source. Don't create a new one."
* Iterating later: "On the Service Desk Triage app, add a fifth KPI tile for reopened tickets this week and move the priority donut above the table. Leave everything else alone."
* Fixing something: "The table on my Patch Compliance page is showing `--` in every cell. Figure out why and fix it."

#### Things to put in the prompt to avoid rework and additional token cost

* Name the branding scheme, if you care.&#x20;
  * "Standard Rewst components" - native, faster and block-editable
  * "Custom branded design" - hand-authored HTML/CSS, more expensive, best for client-facing polish
* Say read-only if it's read-only. Otherwise, you may get buttons you didn't want.
* Say "preview first" for anything that writes to an external system. The Rewst Agent will ask, but stating it up front saves a turn.
* Don't ask for fake data unless you want a throwaway mockup. "Use realistic sample data" produces a demo, not a working app.
* Make one app, ask for one decision. Prompts that ask for tickets *and* licenses *and* patching in one page produce a cluttered surface. Ask for multiple pages instead: "three pages: Tickets, Licenses, Patching, with shared header nav."

## Create a page in an existing app

1. Navigate to the existing app by clicking on it in your **Apps** list. Every app's info page will contain a Pages section where all pages for that app will be listed. Each app you create will have a home page by default, added by Rewst. Both are customizable. For more on App pages, see our pages documentation [here](/rewst-documentation/documentation/apps/app-pages.md).

<figure><img src="https://3039672601-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh0G0em3PH6aDfPoI5XpN%2Fuploads%2F4J7kqn1VeLjwfMbc361g%2FScreenshot%202026-07-27%20at%2011.42.52%E2%80%AFAM.png?alt=media&amp;token=693b95fb-b82d-4de7-b515-c81fd53279d0" alt=""><figcaption></figcaption></figure>

2. Click **New Page**. Give your page a name. Remember that Rewst will create the url slug for that page based off this name. Choose something that makes sense, but is appropriate to be seen by the eventual audience of the page.
3. Click **Create Page**. This will take you to the builder screen for that page. You can then drag, drop, and edit any [blocks](/rewst-documentation/documentation/apps/blocks.md) for that page.

<figure><img src="https://3039672601-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh0G0em3PH6aDfPoI5XpN%2Fuploads%2FmLx4IMMULlnZl3Qu3AKq%2FScreenshot%202026-07-27%20at%2011.44.06%E2%80%AFAM.png?alt=media&amp;token=00f0664d-6923-49ff-9f25-e2be43d77690" alt="" width="302"><figcaption></figcaption></figure>

## Publish an app

Whether you've built your app via the Rewst Agent or manual design, it won't be live for use until you publish your app.&#x20;

1. Ensure that everything in your app looks and functions as desired.&#x20;
2. Open the app’s info page.&#x20;
3. Click its name.
4. Click **Publish App**.

## Delete an app

1. Navigate back to the app list.
2. Click **...** next to the app you wish to delete.
3. Click **Delete**. The app is removed from the list immediately.

{% hint style="danger" %}
&#x20;Once an app is deleted, it cannot be recovered. Exercise caution before deleting an app.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rewst.help/rewst-documentation/documentation/apps/how-to-create-an-app-ask-the-rewst-agent.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.