Who to hire for Fin on Salesforce

The easiest way to understand what to hire for with Fin is to follow a single customer email through your org. A customer writes in. A case is created in Service Cloud. A rule decides who owns it. Something replies. If it cannot finish, someone else takes over, and the whole story is recorded on the case. Every step is a piece of Salesforce design that a partner either understands or does not. Fin sits in the middle of that sequence as an agent, and the person you hire is responsible for everything around it.

Salesforce completed the acquisition on 10 September 2026, and the announcement said: "Salesforce today announced it has completed its acquisition of Fin, formerly Intercom, an industry-leading customer agent company." Fin's own pricing page confirms that the product is not tied to Intercom's helpdesk: "Fin can be used with tools like Salesforce, Zendesk and others." The corporate story is on What happened to Fin, and the design view on Fin, Intercom and Agentforce. This page walks the case and shows where hiring decisions arise.

#Step one: the case is assigned to Fin

Fin's setup guide for Salesforce cases describes the mechanics. Fin is represented by a Salesforce user, and the documentation says: "Fin will reply as this user when a case is assigned to it in Salesforce." It recommends creating a new user for the purpose and making it explicit that it is an AI agent. That user needs the Service Cloud User box ticked so it can reply to cases, and it needs a real email address that is verified in Salesforce. Cases reach Fin through Salesforce's case assignment rules or through Flows, and an administrator can test the connection by changing a case's owner by hand before go-live.

None of this is exotic, but each piece is a place a rushed partner makes a mistake. A shared mailbox used as the Fin user means replies come from an address nobody monitors. A user with a broad profile means the agent can see more than it should. An assignment rule written for human queues may send Fin the wrong kind of case. The first skill you are hiring is ordinary Service Cloud administration: users, profiles, permission sets, queues, assignment rules and Flows.

#Step two: what Fin reads, and when

The sync article is precise about what Fin pulls: "When you deploy Fin for Salesforce cases, Fin will pull all of your Contact, Case, and Account fields from Salesforce." It does this when it is first assigned to a case, and changes made in Salesforce partway through a conversation are not picked up until the next assignment. That detail matters in practice. If your agents routinely update the account owner or a status field while a case is open, Fin may be working from a stale picture. A partner should ask how often your records change during the life of a case and what that implies for the timing of assignment.

The same article explains that Fin syncs inline images and attachments from cases, that a re-sync button exists only for list fields with multiple options, and that Fin can detect attributes only on list fields. These are the sort of limitations to raise in a design workshop, not to discover during user testing. Ask the candidate partner to read the sync article with you and mark which limits affect your data model.

Knowledge is the other input. Fin's guide lists syncing Knowledge articles as the first setup step, and it suggests training Fin on your knowledge base content before connecting. Knowledge quality therefore sets the ceiling on answer quality, and a partner who treats it as someone else's job is ignoring half the product. Ask who will clean and own the articles, how new ones reach Fin, and what happens when two articles disagree.

#Step three: write-back and the fields that matter

Fin writes to the case as it works. Its documentation names two custom fields: FinInvolved, set to true when Fin is assigned a case, and FinResolutionState, which records whether the case was a Soft Resolution, a Hard Resolution, or Routed to team. Fin also writes values such as subject, description, transcript and summary on creation or reassignment, and it can update the case each time it responds.

Those fields are the raw material for every number the business will ask for. This is why price and reporting belong together. As at 13 October 2026 Fin's pricing page says: "Fin is priced at $0.99 per outcome." It counts an outcome when a customer confirms the issue is resolved, when they do not ask for more help after Fin responds, or when Fin completes a workflow, including a hand-off, and it charges only once per conversation. For Fin used with another helpdesk the page shows a monthly minimum of US$49, which includes 50 outcomes, with no seat costs. The licence is a separate subject, covered on Fin Salesforce licence cost, but the hiring consequence is immediate: your reporting needs to reconcile what Fin bills as an outcome with what Salesforce shows as resolved. A partner who can build that reconciliation on FinResolutionState is worth more than one who can only configure the connector.

#Who owns the conversation: Fin or Agentforce

Salesforce has said Fin gives organisations more choice in how they adopt autonomous service alongside Agentforce, and that Fin is quick to deploy with existing help desks. That leaves your org with a design question the announcement does not answer: which cases go to which agent? A sound partner will put it on paper. Some organisations will route routine, well-documented questions to Fin and keep Agentforce for work that needs deeper actions inside Salesforce. Others will start with one and add the other later. Be wary of any partner who recommends moving every conversation to Fin because the deal closed, or who dismisses Fin because they only know Agentforce.

Channel scope belongs in the same decision. Fin's integration article says it pushes live chat data into Salesforce Pre-Chat fields, so a chat deployment needs those fields designed and mapped, which is a different piece of work from email and form cases. Decide the channels first, then the agent.

#Who owns what between you, your partner and Fin

Because Fin is sold as a product with its own onboarding, the cleanest engagements divide the work explicitly. Left vague, each party assumes another is covering the awkward parts, and the awkward parts are where cases get lost.

Write that table into the statement of work, changing the owners to match your organisation, and ask the partner to confirm each line.

#Skills and credentials to look for

Start with the Salesforce Certified Agentforce Service Consultant credential, which Salesforce's exam guide frames around gathering requirements and designing service solutions, with sections on knowledge management, intake and interaction channels, case management, contact centre analytics and integrations. The older Salesforce Certified Service Cloud Consultant credential is still listed on Trailhead and signals the same core experience. Add Salesforce Certified Platform Administrator for users and permissions, Salesforce Certified Agentforce Specialist if Agentforce will share the queue, and Salesforce Certified Platform Integration Architect where connected apps and OAuth need care.

Fin-specific points are not covered by any credential, so ask for experience. One detail worth testing: Fin supports a single active OAuth connection to Salesforce per workspace, with an exception for Knowledge sync across multiple orgs. A multi-org company needs a partner who has thought about that before choosing a design.

#A test script worth insisting on

Before live traffic, ask the partner to run four cases on purpose. One should be a plain question that the Knowledge answers well. One should be a question the Knowledge does not answer, to prove Fin routes it to a person and records Routed to team. One should be a case from a customer whose account data changes partway through, to expose the stale-data limit described above. One should come from a customer who is upset, to check that the hand-over summary is useful to the human who receives it. Keep the results. They become the first page of your acceptance evidence and the baseline for every later change.

#A realistic first engagement

Choose one case type with plenty of volume and well-written Knowledge articles, such as order status, password resets or booking changes. Create the Fin user. Install the permissions package and enable the settings Fin's guide lists. Hand-assign a sample of cases to test, then switch to an assignment rule for a small slice of live traffic. Build the reporting on FinInvolved and FinResolutionState before anything goes live, and agree what a good week looks like. Let your own volumes and approval steps set the timeline, and be suspicious of any plan that promises a date before it has seen your case mix.

#Red flags

Be careful with a partner who treats Fin as a chat widget and does not talk about cases. Be careful with one who plans to connect everything with a broad admin user. Treat a proposal that never mentions escalation with suspicion, because most customer harm comes from the handover, not from the reply. Question anyone who forecasts a resolution rate for your business before seeing your Knowledge, and anyone who wants to count outcomes without the Salesforce fields to check them.

#Ten questions

1. Which Salesforce user will Fin act as, and what can that user see?
2. Which assignment rule or Flow will send cases to Fin, and which cases will it never send?
3. How will you test with manual owner changes before live traffic?
4. How does your design cope with changes made in Salesforce partway through a case?
5. Who owns Knowledge quality, and how do articles reach Fin?
6. How are FinInvolved and FinResolutionState reported, and how do they reconcile to the outcomes Fin bills?
7. What does escalation look like, and what does the human see on the case?
8. Which conversations belong to Fin and which to Agentforce, and who decides?
9. How would you handle more than one Salesforce org, given the single OAuth connection?
10. What would make you advise us to leave a case type out?

#References, commercial terms, and when to skip a partner

Ask for a reference where an agent was assigned cases through rules, and ask what was changed after the first week of live traffic. A reference who can describe a mistaken assignment rule and how it was fixed has done the work. Look for a sample report that separates cases Fin resolved, cases Fin routed, and cases it never saw.

For the engagement, fix the price of discovery and the first case-type slice, and cap the rest. Write into the statement of work the Fin user and its permissions, the assignment rule or Flow, the sync settings, the reporting fields and report definitions, the escalation route, the test plan, and the rollback. Leave out a promised resolution rate. The project view is on Fin Salesforce implementation cost.

You can skip a partner if you run one Service Cloud org, one case type, strong Knowledge and an administrator who can follow Fin's Salesforce cases setup guide. Bring one in for multi-org setups, regulated cases, heavy Knowledge clean-up, or any plan that blends Fin and Agentforce. Read Should I migrate from Fin and Integrating Fin with Salesforce before you decide.