Report Builder
Build Salesforce reports from a plain-English description
Say what the report should show. It reads your org’s report folders and the report type’s actual column tokens first, builds a validated spec, and renders the .report XML into a Development Studio project. You review the columns, filters and groupings before it lands — and nothing reaches Salesforce until you deploy it.
| Report | Folder | Format | Last run |
|---|---|---|---|
Aged Pipeline FY26 Aged_Pipeline_FY26 | Broker | Matrix | 12 Feb 2026, 09:14 |
Broker Register Broker_Register | Broker | Tabular | 3 Sep 2025, 14:20 |
Campaign ROI FY24 Campaign_ROI_FY24 | Marketing | Joined | 15 Aug 2025, 10:12 |
Declines by Reason Declines_by_Reason | Credit | Summary | 19 Jan 2026, 11:47 |
Direct Approvals FY25 Direct_Approvals_FY25 | Marketing | Summary | 4 Apr 2025, 16:02 |
Settlement Forecast Settlement_Forecast | Finance | Matrix | 28 Nov 2025, 08:31 |
Unassigned Leads Unassigned_Leads | Sales Ops | Summary | 22 Dec 2025, 07:05 |
- Report type
- Opportunities with Credit AssessmentsOpportunity_with_Credit_Assessment__c
- Format
- Matrix
- Scope
- organization
- Date filter
- CLOSE_DATE2025-07-01 → 2026-06-30
- Row limit
- Unlimited
- Last run
- 12 Feb 2026, 09:14202 days ago
Groupings
- RowsStage(asc)
- ColumnsClose Dateby Calendar Month
Cross filters
- Opportunity without Credit Assessments
Bucket fields
Deal size
What you can do
- Describe the report in your own words — “open opportunities closing this quarter, grouped by stage, with the amount summed”
- The report type is picked from the list your connected user can actually see, or you pin one yourself
- Grounded generation: the org’s real folders and that report type’s real column tokens go into the prompt, so it looks OPPORTUNITY_NAME up rather than inventing Opportunity.Name
- Tabular, Summary and Matrix, with each format’s own rules enforced — a Summary needs a row grouping, a Matrix needs both, a Tabular can carry neither
- Up to 60 columns, 20 filters, three row groupings and two column groupings
- The complete Metadata API operator list — “does not contain”, “includes” and “excludes” included — plus explicit boolean filter logic like “(1 OR 2) AND 3”
- A standard date filter over the usual intervals or an explicit start and end, and date groupings bucketed by day, week, month, quarter, fiscal quarter or year
- Summary functions (Sum, Average, Max, Min, Unique) checked against the column’s real data type before anything is written
- Top-N tabular reports through a row limit and a sort column
- Every column, filter, grouping and sort validated against the report type up front — each problem names the offending token instead of failing in a deploy an hour later
- A review pane shows what was built before the file joins your project
- When the folder does not exist yet, its .reportFolder is written alongside so the pair deploys together
- The Reports explorer inventories every report, folder, report type and dashboard in the org, with “never run” and “not run in 180 days” filters
- Report definitions read out in full — columns, filters, groupings, cross filters, bucket fields and custom summary formulas
- The same authoring tool is exposed over MCP as create_report, so an assistant can add a report to a project the same way
How it works
Say what it should show
A description, a folder to file it in, and either a report type you have chosen or “let AI choose”. The API name is optional — it is derived from the title otherwise.
It grounds itself in your org
Two passes: pick the report type from the org’s own list, then build the spec against that type’s actual columns. A hallucinated token becomes a validation error rather than a plausible wrong answer.
Review before it lands
The columns, filters and groupings are shown as a summary, with any warnings, so the first look at the report is not a wall of XML.
Deploy when you are ready
The .report is an ordinary file in a Development Studio project. Editing it, versioning it and deploying it all work the way the rest of the studio does.
Why it's different
A checked spec, not a wall of generated XML
Ask a model for report XML directly and you get XML that looks right and fails the deploy on element order, an operator that does not exist, or a grouping on a format that cannot carry one — and the feedback is a Salesforce parse error that names neither the element nor the position. Here the model fills in a narrow, enumerated spec instead: the wrong answers are unrepresentable, what remains is checked against the report type’s real columns before anything is written, and the XML itself is the output of one tested function. Then it lands in a project rather than in your org, so deploying stays a deliberate step you take.
Try asking
- Rebuilding a report someone deleted, from a description of what it used to show
- A matrix of cases by priority across the month they were opened
- Open pipeline by stage with the amount summed, excluding anything under $5,000
- Finding the several hundred reports nobody has run in six months, before a migration
- Checking which report type a report actually depends on, and what its cross filters and bucket fields do
Report Builder — questions
Replacing something?
- orgadmin.ai vs Agentforce
Salesforce’s platform for customer-facing AI agents. Compare when what you wanted was AI for the people who run the org.
Read next
- How to build Salesforce dashboards across multiple objects
When two objects share only an indirect relationship, forcing them into one report can duplicate rows and distort totals. Start with grain, not the chart.
- Agentforce, Einstein, or your own AI key?
Salesforce sells AI licensed per user for customer-facing agents. Most admin teams want something quite different — and the pricing reflects that mismatch.
Put Report Builder to work on your org
Every AI feature on your own provider key, from A$14.99 per user per month.
- 14-day free trial
- No credit card required
- Cancel any time