LinkedIn
Every Salesforce team has a queue of change requests that are vague, duplicated or missing the detail needed to act on them. TriageMate is an Agentforce agent that refines each request, asks the requester clarifying questions, and recommends a priority and a route - so the team spends its time building, not chasing information.
What it does:
- Finds untriaged requests, by priority, and summarises the business need
- Classifies the request type and highlights missing information
- Writes clarification questions and drafts acceptance criteria
- Recommends a priority and where the request should go next
- Leaves the final decision with the team
It follows a Salesforce BAU triage playbook held in a Data 360 library, so its recommendations are consistent and explainable. The result: a vague request becomes a work request a person can act on. TriageMate was the first in my series of Salesforce Mates.
Grounded in a playbook
The TriageMate Agent Action Playbook, held in a data library, is the agent's main source. For each request the agent uses it to classify the request type (a new field, a flow, an approval process, a report, access and security, a defect, an integration, data clean-up or a new process), identify missing information, draft clarification questions, suggest acceptance criteria, recommend a delivery route and recommend the next triage status. Broad or unclear requests are routed to solution design.
If a request falls outside the playbook, the agent says so and gives a cautious recommendation rather than pretending the playbook covers it.
The requested priority is not the recommended priority
Each request keeps the requester's original description and requested priority next to the agent's refined description, recommended priority and route. The agent treats the requested priority as what someone asked for, not as a fact. Human review fields sit alongside, so it is always clear what the agent suggested and what a person decided.
The team stays in control
The agent saves its assessment back to the request only when the user clearly asks it to. It may not say that a request has been approved, prioritised, assigned or delivered unless an action has actually done it. Approval for build remains a team decision.
What I would tell another team
- Write the playbook first: it is what makes the agent consistent and explainable
- Keep the original request next to the agent's version
- Do not let the agent claim anything it has not done
I design, build and review agents like this as an Agentforce consultant in the UK.