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
Image QA dashboards
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.
Custom intake forms
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.
Ticket-backed dashboards
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.
Cross-channel views
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 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
1
Describe the view you want
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.
2
Review what Grady builds
The app appears in the task. Check that the numbers match what you expect before anyone else relies on it.
3
Iterate in conversation
Ask for changes the way you’d ask a colleague — add a column, group it differently, chart the trend instead of listing rows.
4
Share it
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
Related
- Ask Grady → — asking Grady questions about your Gradial data directly, without building an app
- Integrations → — connecting the systems an app can report on
- Digital Asset Management → — asset governance the QA dashboards report on
- QA Reports → — the underlying quality checks
- Cross-Channel Campaign Execution →