feat: service agent recipe with dx pipeline#93
Conversation
…ment Promotes the CustomerServiceAgent from future_recipes to a new force-app-service/ package directory typed as AgentforceServiceAgent. Adds cross-platform Node.js scripts to create the org-specific agent user and inject it into .agent files at deploy time, with a pre-commit hook to restore the placeholder before commits. CI workflows updated to deploy service agents sequentially after employee agents. Closes #58
…d install scripts The service agent user needs the data permset to access recipe objects. Previously this was a vague post-install note. Now it's automated in CI workflows, install scripts (sh + bat), and documented as an explicit README step with the exact command.
… reduce to 3 subagents The recipe now focuses on demonstrating the Service Agent differentiator (agent_type + default_agent_user) with a clean 3-subagent flow: router → triage → resolution. Drops unused update_case and send_satisfaction_survey actions along with their backing metadata.
Moves all CustomerServiceAgent metadata into force-app-service/customerServiceAgent/ to match the per-recipe folder structure used in force-app/main/. Adds a detailed recipe README and updates all path references in CI, install scripts, and AGENTS.md.
Without collect_info, the available when guards on all triage actions stayed permanently locked because nothing wrote user input into variables. The LLM now calls collect_info first to extract customer_id and issue_description, which unlocks downstream actions.
…ploy failure Move IssueClassifier class access and Contact.Customer_ID__c, Contact.Loyalty_Tier__c, Case.Escalation_Reason__c field permissions into a dedicated Customer_Service_Agent_Data permission set inside force-app-service. This eliminates the deploy error where the shared permission set in force-app referenced fields that only exist in force-app-service.
… stdout - Move node scripts (setup-service-agent, clean-service-agent, validate-agents) from bin/ to scripts/ - setup-service-agent now writes username to stdout and logs to stderr, eliminating the brittle grep against .agent files in CI - CI steps capture username via GITHUB_OUTPUT step outputs - Add clean:service-agent npm script - Activate EscalateCase flow - Remove .vscode bin exclusion
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Salesforce Code Analyzer found 82 violations, including 0 in files changed by this pull request. See job summary page.
CreateCase only accepts subject and outputs case_number (not case_id). EscalateCase is a stub that returns hardcoded outputs without DML.
msrivastav13
changed the title
msrivastav13
changed the title
There was a problem hiding this comment.
Salesforce Code Analyzer found 82 violations, including 0 in files changed by this pull request. See job summary page.
msrivastav13
added
bug
There was a problem hiding this comment.
Salesforce Code Analyzer found 82 violations, including 0 in files changed by this pull request. See job summary page.
There was a problem hiding this comment.
Salesforce Code Analyzer found 82 violations, including 0 in files changed by this pull request. See job summary page.
|
Thanks for adding this @msrivastav13. I wonder if this shouldn't be a standalone example repo somewhere (similar as we have in Coral Cloud), as recipes are meant to be for Agent Script specifics. |
I think it can go either way. In my opinion this is all still Agent Script specifics. It shows Agent Script of type By having a framework like this we can show Agent Script specifics like linked variables that are exclusive to AgentforceServiceAgent that we wont be able to show otherwise. The other idea is we could make Service Agent class of recipes optional and then its up to the developers to decide to follow those along...Thoughts on this approach? |
|
Thanks for taking care of this @msrivastav13, I was also looking into it for an updated Coral Cloud demo with the new builder. The PR looks good but my experiments showed that you also have to update the agent username in the related |
@pozil Is it not a bug then in the Agent Script transformation to Bot metadata? Because this takes care of populating that user on the Agent Script level and my assumption is we do not ever have to deal with that Bot metadata. Let me know and I think we can talk to DX team if this is something that can be done at CLI level itself |
|
IDK what's the expected behavior but I guess that the bot metadata is created when you activate the service agent. |
Yes for testing this out in my scratch org, I did not face this issue. I am on Summer orgs. I was able to commit of the UI because deploys were successful and then activate all fine. Test this recipe out @pozil in a org and let me know if you see gaps. |
|
I confirm that it works with the agent in draft mode (no need for the bot metadata update). However, the escalation use case example from the readme didn't work on my end: it didn't escalate because it found an [unrelated] knowledge base article. |
Thank you for testing. Will get this feedback addressed. |
There was a problem hiding this comment.
Salesforce Code Analyzer found 82 violations, including 0 in files changed by this pull request. See job summary page.
@pozil I did some more iterations on the instructions and the script. Let me know if you see anything else. |
pozil
left a comment
pozil
left a comment
There was a problem hiding this comment.
All good apart from the API version. I'll let you merge directly once it's fixed.
| <?xml version="1.0" encoding="UTF-8" ?> | ||
| <Flow xmlns="http://soap.sforce.com/2006/04/metadata"> | ||
| <apiVersion>66.0</apiVersion> | ||
| <apiVersion>60.0</apiVersion> |
There was a problem hiding this comment.
@msrivastav13 can you revert this and make sure that we're on the latest API version for all metadata?
There was a problem hiding this comment.
Thanks I updated this. @muenzpraeger Anything special needs to be done to show on the agent script recipes?
There was a problem hiding this comment.
Salesforce Code Analyzer found 82 violations, including 0 in files changed by this pull request. See job summary page.
3 participants
What does this PR do?
Adds a complete Agentforce Service Agent recipe (CustomerServiceAgent) with a full developer experience pipeline for agent user management. Service Agents differ from Employee Agents by running under a dedicated agent user rather than the logged-in user — this PR demonstrates that pattern end-to-end with deploy-time placeholder replacement and pre-commit cleanup.
Key changes:
searches a knowledge base, and creates or escalates cases using subagent transitions, Apex
(IssueClassifier), and Flows
AGENT_USER_PLACEHOLDER in .agent files; scripts/clean-service-agent.js restores it before
commits via a pre-commit hook
cross-directory deploy failures with the shared permission set
the agent user using GITHUB_OUTPUT step outputs (no brittle file grep)
outputs the username to stdout for clean shell capture
What issues does this PR fix or reference?
#58
The PR fulfills these requirements:
[ ] Tests for the proposed changes have been added/updated.
[ ] Code linting and formatting was performed.
Functionality Before
Functionality After
force-app-service
.agent files
eliminating the cross-directory dependency