> ## Documentation Index > Fetch the complete documentation index at: https://docs.gradial.com/llms.txt > Use this file to discover all available pages before exploring further. # Custom Apps > Turn a prompt into a governed dashboard, report, or intake form built on your live Gradial and connected system data — authored by Grady, refreshed on demand, and scoped to each viewer's permissions. ## Overview Every team ends up wanting a view that no standard report gives them: the assets that failed QA this week, a running intake queue for creative requests, campaign progress across web, email, and social in one place. **Custom apps** are Grady-built applications that answer exactly that. You describe the view you want, and Grady generates a working app — dashboards, reports, and forms built on live data from Gradial and from your connected systems — that lives in the task and refreshes against current data whenever you open or refresh it. They're not hand-built. You don't configure widgets or write queries. You describe what you need to see, and iterate with Grady until it's right. **Access:** Must be enabled for your organization. Contact your Gradial team to get access. *** ## What you can build Surface which assets passed or failed quality and accessibility checks, what's missing alt text, and which items need a human look — reading straight from your connected DAM, across a campaign delivery rather than one asset at a time. Stand up a request queue in minutes. Teammates submit structured requests through a form, submissions are stored with attribution, and Grady picks the work up from there. Report against your connected ticketing system — what's open, what's blocked, what's aged past its SLA — without exporting to a spreadsheet or waiting on someone to build a Jira view. Pull campaign data spanning web, email, and social into one dashboard, drawing on each connected platform, so progress and gaps read at a glance instead of channel by channel. **The system has to be integrated.** Custom apps read your Gradial data — tasks, artifacts, activity, and shared records — plus data from any system Gradial is connected to, such as an external DAM or your ticketing system. If Gradial isn't integrated with a system, an app can't report on it. See [Integrations](/docs/integrations-administration-and-setup/integrations/get-started-with-integrations) for what's connected today. *** ## The three building blocks Every custom app is some combination of these. ### Live, governed data Apps query your tasks, artifacts, activity, and shared records directly — and, where Gradial is integrated with a system, that system's data too — rather than working from a snapshot someone exported. Refreshing an app re-runs its queries against current data. This is what makes a custom app different from a spreadsheet export: the export is stale the moment it's made, while the app reflects the state of your DAM, ticketing system, or campaign platform at the moment it's refreshed. Every query is read-only, scoped to the permissions of whoever is viewing, and audited. An app can't change your data — in Gradial or in a connected system — only read and present it. ### Generated interfaces From a single prompt, Grady builds the interface to match the data: metric strips for headline numbers, responsive tables, and charts, with proper loading and error states rather than a blank panel when something is slow. ### Forms and actions Apps can collect input as well as display it. Form submissions are stored as attributed shared records — you always know who submitted what and when — and Grady can read those submissions back and act on them. This is what turns a dashboard into a workflow. An intake form isn't just a record of requests; ask Grady to process the queue and it works from those same submissions. For example, collecting requested DAM metadata rewrites through a form, then asking Grady to apply them. *** ## Building one Say what you need to see and who it's for. "A dashboard of every asset we uploaded this month that's missing alt text, grouped by campaign" is enough to start. The app appears in the task. Check that the numbers match what you expect before anyone else relies on it. Ask for changes the way you'd ask a colleague — add a column, group it differently, chart the trend instead of listing rows. Teammates open the app and see it rendered against the data they're permitted to see. *** ## Designing apps that work well **Go aggregate-first.** The queries behind an app are deliberately bounded — read-only, a few seconds, a couple hundred rows. Summary views, counts, groupings, and rollups perform well. A long list of raw records is the wrong shape; ask for the summary and drill in from there. **Expect results to differ between viewers.** Because every query runs with the viewer's permissions, two people can open the same dashboard and correctly see different numbers. That's the governance model working, not a bug — but it's worth saying out loud when you share an app with a wider group. **Refresh is on demand.** Apps re-query when someone refreshes them rather than polling continuously, so the data is current as of the last refresh rather than streaming live. **Submitting and processing are separate steps.** Form submissions are stored immediately, but Grady acts on them when you ask it to. An intake form fills up on its own; working the queue is a request. *** ## Example prompts ``` Build me a dashboard of every asset uploaded to the Spring campaign folder this month, showing which ones failed QA and which are missing alt text. Group by sub-campaign and show the totals up top. ``` ``` Create an intake form for creative requests — requester, campaign, channel, deadline, and a description field — and a table underneath showing everything submitted so far. ``` ``` Build a report on our Jira queue this quarter: how many issues are open, how many are blocked, and which have been waiting longest — grouped by project. ``` ``` Give me one dashboard covering our Q3 campaign across web, email, and social — pull from the CMS, the email platform, and our social data so I can see what's shipped, what's in review, and what hasn't started. ``` *** ## Related * [Ask Grady →](/docs/getting-started/ask-grady) — asking Grady questions about your Gradial data directly, without building an app * [Integrations →](/docs/integrations-administration-and-setup/integrations/get-started-with-integrations) — connecting the systems an app can report on * [Digital Asset Management →](/docs/asset-management/digital-asset-management) — asset governance the QA dashboards report on * [QA Reports →](/docs/quality-assurance-and-accessibility/qa-report) — the underlying quality checks * [Cross-Channel Campaign Execution →](/docs/campaign-management/cross-channel-campaigns)