Story Agent
The Story Agent is a conversational assistant that turns natural-language change requests into a hierarchical backlog -- EPIC → FEATURE → USER STORY with Given / When / Then acceptance criteria -- grounded in your latest aprity scan. Once a backlog is validated, the Story Agent pushes it straight into your tracker (Jira Cloud, Azure DevOps, or Slack) so you never re-type a story.
The Story Agent is exposed as the Story Agent tab inside the aprity managed app, as a backlog panel in Jira and Azure DevOps, and via a Slack slash command -- whichever surface fits your team's workflow.
You may see this feature referenced as Documentation Agent in some places (the tab in the aprity managed app, older marketplace listings). It is the same agent -- naming is being unified to Story Agent across the product and integrations.
How it works
-
Describe what you need in plain language : "add an approval workflow on Opportunity above 100k", "migrate the Lead conversion to a screen flow", "document the impact of deactivating the AccountTrigger".
-
The agent runs on the shared agentic orchestrator, querying deterministic knowledge tools built from your scan (object dossiers, fields, execution order, access/permissions, ownership, dependencies, impact analysis, integrations) and asks a few clarifying questions when needed. There is no vector search or retrieval over chunks -- every fact comes from your scan's structured index.
-
It proposes an IMPACT MAP -- which Salesforce objects, automations, and integrations are touched by the change -- and asks you to confirm.
-
It generates a hierarchical backlog with one of three shapes :
- EPIC -- one high-level theme, usually the change you described.
- FEATURE -- coherent groups of stories within the EPIC.
- USER STORY -- a vertical slice (PATH / DATA / RULE / INTERFACE / SPIKE) with a Given / When / Then acceptance criterion and a complexity hint.
-
Review, refine, validate. The result can stay inside aprity, be pushed to your tracker, or both.
The agent only sees the metadata captured during the last successful scan. If a recent change is missing from its answers, run a fresh scan first.
Backlog structure
Every generated backlog is a strict 3-level tree :
| Level | Format | What it captures |
|---|---|---|
| EPIC | EPIC-001 | The change theme as a whole. Usually one per conversation. |
| FEATURE | FEAT-001, FEAT-002, … | A coherent group inside the EPIC. Typically 2–5 per EPIC. |
| USER STORY | US-001-A, US-001-B, … | A vertical slice of behaviour with acceptance criteria. Typically 3–8 per FEATURE. |
Each USER STORY ships with :
- A title in user-story form ("As a … I want … so that …").
- A Given / When / Then acceptance criterion grounded in the scanned automations and validation rules.
- A complexity hint (T-shirt size : S / M / L / XL).
- Impact tags -- which Salesforce objects, automations, and integrations the story touches.
- A vertical-slice marker (PATH / DATA / RULE / INTERFACE / SPIKE) so the team can sequence work without horizontal slicing.
Push to your tracker
Once a backlog is validated, the Story Agent can write it straight into your team's tool of choice :
- Jira Cloud -- one issue per EPIC / FEATURE / USER STORY, parent-child relationships preserved, custom fields populated. See Jira Cloud — Story Agent.
- Azure DevOps -- the equivalent work-item hierarchy (Epic → Feature → User Story / Task). See Azure DevOps — Story Agent.
- Slack -- the backlog is posted as a thread in the configured channel, with each story as a reply. Useful for review before pushing to a tracker. See Slack — Story Agent.
- No tracker -- you can also keep the backlog inside aprity and review it on the Story Agent surface, or push it later.
The push is idempotent : re-running it on the same conversation matches stories already created in the tracker by their stable reference (EPIC-001, FEAT-001, US-001-A) and skips them, so re-running does not produce duplicates. Each item carries a link back to the aprity conversation so the team can navigate between aprity and the tracker.
Plan availability
The Story Agent is included on Intelligence and Trial plans. It is not available on Documentation.
Each tenant has a monthly credit budget configured during onboarding :
| Plan | Monthly credit budget |
|---|---|
| Documentation | Not included |
| Trial | 10 credits / month |
| Intelligence | 100 credits / month |
One credit is consumed per LLM call the agent makes. A simple conversation typically uses 3–6 credits ; complex multi-turn refinement can use more. The Story Agent tab shows the current usage and the next reset date. When the budget is exhausted, the agent stops accepting new conversations until the next reset or until your aprity contact raises the cap.
See Plan Comparison for the full feature matrix.
Surfaces where the Story Agent lives
| Surface | When to use it |
|---|---|
| Story Agent tab in the aprity managed app | Generate, refine, and export a backlog from inside Salesforce. The natural choice for Salesforce admins and BAs. |
| Jira backlog panel (Forge app) | Generate stories without leaving Jira. The panel is added to your project once you install the Forge app and link your aprity tenant. |
| Azure DevOps work-items extension | Same idea for ADO Boards / Backlogs. |
Slack /aprity slash command | Prototype a backlog directly in a Slack channel ; useful for review with the team before committing to a tracker. |
All four surfaces talk to the same Story Agent on the aprity side, share the same monthly credit budget, and operate against the same scan -- there is no per-channel duplication of data or credit.
Limitations
- The agent does not read your org live. It only sees the metadata captured by the most recent successful scan.
- Backlogs are scoped to a single connected org per conversation. To work across orgs, switch the active org from the aprity app header.
- Credit budgets reset at the start of each calendar month. Unused credits do not roll over.
- Generated stories are paraphrased from the scanned metadata. They are accurate to what was scanned, but they should be reviewed by a human BA / PM before being committed to a sprint -- treat the output as a first-pass backlog, not a contract.
- The push to the tracker creates new items and updates existing ones but does not delete items that have been removed from the aprity conversation. To clean up stale items in the tracker, manually delete them.
Troubleshooting
| Issue | Resolution |
|---|---|
| The Story Agent tab is hidden | Verify your plan includes the Story Agent (see Plan Comparison). The tab is hidden on Documentation. |
| Answers feel outdated | Run a new scan, then start a new conversation. Existing conversations keep referring to the scan they were created against. |
| Monthly credits reached | Wait for the next reset, or contact sales@aprity.ai to raise the budget. |
| Empty backlog | Confirm the scan covered the objects you are asking about. Widen the scope in Analysis Configuration if needed. |
| Push to Jira / ADO / Slack failed | See the respective tracker integration page : Jira, Azure DevOps, Slack. |
For anything else, contact support@aprity.ai.