Support email · Salesforce Cases Switch to Website chat
Evaluation brief · Salesforce Agentforce Service (formerly Service Cloud)
Alex asks to freeze card ending 4242 and review the unfamiliar Metro Store charge.
Alex emails support about an unfamiliar card charge and asks to freeze the card.
Which support addresses are in scope, and which requests Fin should try first.
An illustrated version of the fictional request used in our Fin email demonstration. It is not a delivered email.
Staged Case: the card request and customer details are recorded together. Your configured rules determine whether Fin or a person receives it.
Explanatory diagram
Eligible requests
Other requests
Your assignment rules and inclusion criteria determine which Cases reach Fin. Requests outside that scope stay with your team.
Alex’s card request is shown on a Salesforce Case. In a connected email setup, your intake and assignment rules determine which requests reach Fin.
Which Cases go to Fin, and which must stay with a person.
A synthetic Case was created manually in our Salesforce demo org. Its original request is shown here; this capture does not establish Email-to-Case or a routing-rule execution. Source: How Fin integrates with Salesforce.
Fin explains that a specialist needs to review the request. The email example does not perform a freeze.
From the screenshotFor billing disputes such as an unfamiliar charge, the next step is to have a human support agent review the case. These situations require manual review and cannot be resolved automatically.
You can request a human agent directly in this conversation so the case can be reviewed further.
Fin’s reply is visible on the matching demo Case. Email delivery and a change of owner were not tested.
In this email example, Fin explains that a specialist must review the card request. It does not perform a freeze.
Which content, guidance and Case context Fin can use.
The illustrated reply is adapted from the response observed in native email Preview. Fin-authored activity also appeared on the manually created demo Case. Email delivery and automatic owner reassignment were not verified. Source: Fin Guidance.
Demo Salesforce Case · HTML transcription
Case 00001018
Selected content transcribed from a demo Case. Status and follow-up details were staged manually. No freeze was performed; email delivery and automatic handover were not verified.
Description
Alex Morgan reports an unfamiliar $129 Metro Store charge on card ending 4242 and requests a freeze and dispute review.
Fin-authored feed post — excerpt
You can request a human agent directly in this conversation so the case can be reviewed further.
Follow-up note — manually staged
Email Preview asked Alex to request a human agent. No freeze was performed.
Next step: specialist reviews the card request and disputed charge.
What the demo Case shows
From the screenshotEmail Preview asked Alex to request a human agent. No freeze was performed.
Next step: specialist reviews the card request and disputed charge.
The request, Fin-authored activity and Case details are visible together. A specialist still needs to review the card request.
Explanatory diagram
Configured destination
Your Salesforce automation
Fin can write configured Case context. Your handover destination and the setting for running Salesforce assignment rules determine ownership. A summary alone does not assign a team; test the saved fields and owner.
The specialist needs Alex’s original request, the disputed charge and the work still to do. Your settings determine who receives the Case.
When to hand over, who receives the Case, and what context they need.
The follow-up description and status were staged manually. This is a native Case example, not an automatic Fin handover or completed banking operation. Source: How Fin integrates with Salesforce.
One fictional card request, with illustrated emails and native Salesforce examples. No real banking action.
12 checks in four stages. Stages 1–2 are facts to gather with your Salesforce admin; stage 3 is specific to the Support email route; stage 4 is what you agree and test before go-live.
Confirm with your Salesforce account team that your edition includes Web Services API access: Agentforce Service Core, Advanced and Max include it; Pro Suite needs the API add-on, while Starter Suite does not include it.
Salesforce edition comparison. On legacy editions, Enterprise, Unlimited and Performance include API access; Professional requires the Web Services API add-on. Developer Edition includes API access for testing. API requirements. Additional API Calls increases an allowance; it does not enable API access. API add-on guidance.
For support email, confirm with your Salesforce administrator that your support inbox feeds into Email-to-Case and your edition includes Case management and web/email case capture; Agentforce Service Core, Advanced and Max include those features.
Salesforce edition comparison. Email-to-Case editions lists legacy editions too. Cases setup guide. Feature inclusion alone does not establish compatibility with every Fin setup.
Confirm with Fin that your plan includes the Salesforce integration.
Fin plan requirement. Fin's public setup guide specifies this entitlement rather than a named plan tier.
Treat Salesforce Knowledge as optional. If your team authors help articles in Salesforce, confirm with your Salesforce account team whether your edition includes it: Advanced and Max include Knowledge read/write, while Core offers it as an add-on.
Salesforce edition comparison. Fin's Salesforce sync accepts published articles that are public or visible to logged-in users; other audience targeting is excluded. Knowledge sync guide.
Choose the inboxes and Case types Fin should handle.
Support addresses need verification in both systems. Include web-form Cases only if that intake is in scope. Cases setup guide.
Identify the Case information Fin needs at the start of a request, and account for the fact that Fin does not automatically refresh changed Salesforce fields mid-session.
Cases data guide. Requests needing fresher information should be scoped explicitly.
Choose the receiving Salesforce team or queue, and tell the customer what to expect next.
Check the resulting Case owner, handover summary and follow-up thread. Cases data guide.
Set the target the trial is judged against and when you will measure it. Then test an answer, missing information, a handover to a person and a failed request, checking what the customer sees and the Salesforce record.
Name who judges the trial and who signs off configuration, content, security and go-live. Name who keeps help content accurate, who can pause Fin, and how your team takes over.
Case conversations and Salesforce Case, Contact and Account fields available to the integration. Salesforce Knowledge is a separate content sync.
Replies, Case context and Fin outcome fields. Handover can set the Case owner; Contact and Account updates have a separate control.
Salesforce access, content sources, workflow actions and handover rules. Guidance shapes answers; it does not grant data access.
For Cases, start with your existing intake and decide which requests should reach Fin. Fin's email setup includes address verification. Review automatic replies and assignment rules together, then test the sender, thread and destination queue.
Choose Case follow-up when customers can wait for a reply. Choose live handover when they need to keep chatting with your team. Decide from the service experience you need, then check the matching channel requirements.
Yes. With Cases, the team works the Case. With Messenger, choose between creating a Case for follow-up and live handover to an agent in Salesforce. Confirm the applicable chat setup using the checklist above.
Agree the destination, customer message and expected response for out-of-hours requests. Include a test with no available agent. Do not assume the live handover experience is also your after-hours experience. See check 4.1.
Selected published articles can sync into Fin. Check audience restrictions and publication status with your knowledge owner. Keep edits in Salesforce and check the sync before relying on a changed answer. See check 1.4.
For Salesforce Cases, Fin refreshes field values when it is assigned a Case. Changes made during that session are picked up on the next assignment, not while the session is running. This is separate from Knowledge article sync.
Define what a visitor can ask anonymously and what needs verified identity. Your administrator and security owner approve the identity checks, fields and actions for the selected route. Test a signed-out or unverified user as well as a recognised customer. See check 2.1.
The schedule depends on missing content, how many hours a week your Salesforce admin can give, security review and approval of changes. We agree milestones after checking those.
Yes. Start with a few common, low-risk requests and list the ones that must always go to a person. Before go-live, agree who can pause Fin, how new requests return to your team and what happens to work already in progress. Test that fallback in your environment. See check 4.2.
A short agenda for your first implementation conversation.
Choose the starting pointBring these to the first conversation
Agree the workPut these in the written scope
Answer what you know. “Not sure” is fine. Review and copy the brief to share with your team or with us.
Your answers stay on this page until you copy or download them. Nothing is submitted automatically.
Planning the trial with your team? The shared trial brief asks the same first questions and saves each answer with Flownetic as you go.
The first conversation checks your route, what is still missing and the work to scope. A written proposal follows; configuration and test results come during the agreed engagement.
Request a 30-minute call Opens a Google Calendar booking page
What to have ready for the call: what the trial should prove, which requests Fin should try first, where customers should reach it, and your rough monthly support volume.
Planning a trial? Prepare a shared trial brief with your team: sign in, and answers save as you go.