Integrating Fin with Salesforce

A service director hears that the Fin deal has closed and tells the steering group that every Service Cloud org now includes it. Two agents are switched on for the same queue: the one the company already runs, and Fin, because the logos now share a parent. Customers receive two replies, or they receive a reply from neither, because each agent believes the other owns the next step. The plan on the slide is a containment rate with no denominator. The rate survives the meeting. The ownership of the conversation does not.

Take the rate off. Then write the integration as two decisions and a failure. Which agent answers. What happens on the handoff. The failure is two agents both owning the conversation. Fin, formerly Intercom, is not automatically inside every Service Cloud org. A close date does not flip that switch.

The scope of customers, intents, and handoff, without a made-up rate, is Fin, formerly Intercom, after the acquisition closed. The corporate record is What happened to Fin. This page is the diagram of the conversation itself. Stay here until you can say who answers, and what the other agent is forbidden to do.

#What the cited page says

The sentence this page quotes is the investor release: "Salesforce today announced it has completed its acquisition of Fin, formerly Intercom, an industry-leading customer agent company." The completion date is 10 September 2026. Fin, formerly Intercom, is the company named. Completed means the deal is done. Formerly is the name the release itself uses. People will search both names. Your contract may say one, or the other, or both. Follow the paper you signed.

The sentence does not say that every Service Cloud org includes Fin. Service Cloud is a product many companies already run. Fin is a customer-agent company that has been acquired. Those are not the same fact. An org that never bought Fin does not wake up inside the product because a parent company changed. If you cannot find Fin in the org, that absence matches this source. It is not a hidden menu you should ticket into existence.

The sentence does not publish a containment rate. Do not invent one. Containment is a ratio someone has to define: which conversations, which channels, whether a customer who returns still counts, whether a forced handoff counts as contained. None of that is in the release. A number from a conference, a rival, or a tidy business case is not your denominator. A target given to a team before a pilot will bend the work. People will close conversations the customer does not consider finished, or they will avoid a handoff the policy requires, because the rate is now a score. Leave the number out.

No screen, no API name, no daily cap, no price, and no connector name appears in the sentence. This page will not supply them. The integration you are allowed to specify is ownership of a conversation, not a product module you have not been shown.

#The system

The system is the pair of agents that might speak, and the Service Cloud conversation they might both try to own. Name them as a pair only if both exist in estates you actually have.

First, establish whether you have Fin at all. Does a contract say Fin or Intercom. If it does, you are dealing with a service you already bought, now under a completed acquisition. Your questions are about continuity and about how that service sits beside the Salesforce org you also run. If it does not, you do not become a Fin customer by owning Service Cloud. Wanting to become one is a purchase. It is not a weekend configuration, and it is not an integration you can draw in advance of the purchase.

Second, name the agent that already answers, if one does. A bot, a human queue, an agent you configured yourselves. It has an owner. Fin, if you have it, has an admin who may not be the Salesforce admin. Write both names down. A rollout note that tells every Salesforce admin to "enable Fin" creates tickets they cannot close. The enablement, if it exists, is on the contract, not in a rumour about the close.

The system is not "Service Cloud, with Fin inside it" as a single box. That box is how two agents get switched on together. Draw them as separate, then draw the one line that matters: who is allowed to answer. A single box cannot carry that line. It can only imply that both are on, which is the failure.

Channels matter, and this page will not invent your channel list. Phone, chat, and mail are different conversations even when they concern one customer. Say which channel this design covers. A design that says "all service" will double-reply on the channel nobody remembered. Start with one channel you can watch.

#The object

The object is the conversation. One conversation, one owner at a time. The owner is the agent allowed to answer. The other agent does not also answer, does not also close, and does not also promise a next step.

Which one answers is the integration. Write it as a rule a supervisor can apply. For this kind of request, on this channel, this agent speaks. For another kind, the other speaks. Where you are unsure, a person speaks, or the conversation waits. Unsure is not a reason for both to speak. Customers do not experience two helpful replies as twice the service. They experience a contradiction.

The handoff is the other half of the object, not a footnote. When the answering agent stops, what moves. The history the next owner must see. The history they must not see, if it includes something the next room is not allowed to have. Who tells the customer the owner changed. What the first agent is forbidden to do after the handoff. A handoff that is only a status flag, with both agents still able to send, has not handed anything off. It has labelled a conversation that still has two owners.

Do not split ownership by sentence. One agent greets, the other resolves, both stay live. That feels sophisticated. It is two owners. If you want a greeting from one and a resolution from the other, the rule has to say the first stops before the second starts, and the customer hears one voice at a time. Write the stop. Test it. A transcript with two closings is a failed object, even if both closings were polite.

There is no object called "the containment". A rate is not a conversation. Chasing it will damage the object you do have. Keep the object as the conversation, the owner, and the handoff. Leave percentages for a definition you have not been given and should not invent.

#The failure

The failure is two agents both owning the conversation.

It shows up in the transcript. Two greetings. Two answers that disagree. A customer told to wait by one and told the case is closed by the other. A human picks up a conversation an agent is still writing in. An agent writes after the human has taken it. Each of these is the same failure. The integration did not decide. Both sides stayed on.

It also shows up as a gap, which is the twin of the double reply. Each agent defers, because each believes the other owns the next step. The customer sees silence. Silence and double reply come from the same missing rule. The rule is which one answers, and the moment the handoff completes so the first must stop.

Test with a scripted conversation on the one channel you named. Start with agent A as owner. Ask something that should hand off to agent B. The pass is one answerer at a time, a customer-visible handoff, and no further message from A after the handoff. The fail is any message from both after the handoff point, or a stall where neither will speak. Run it with the identities you will use in production. A test in which an administrator forces the owner flag, while both senders remain enabled, has not tested the failure.

Do not add a third agent "to supervise" and call the conflict resolved. A supervisor who also sends is a third owner. Supervision that only watches is a log. The log is useful. It is not a substitute for the rule.

#The diagram

A diagram that does not name the system, the object, and the failure is a poster. The poster here is a Service Cloud shape with Fin inside it and a percentage in the corner. It names none of the three decisions. Use the table.

If the system cell says "all orgs", it is wrong. Replace it with the contract you hold, or with "not in this org". If the object cell is a containment rate, rub it out and write the handoff. If the failure cell is "bot did not understand", you are testing a different problem. Understanding can be poor and still have a single owner. Two owners is the failure this integration is about, even when both answers are fluent.

No connector name and no screen. You were not given them. The handoff rule is the buildable picture.

#What you write before a second agent is allowed to speak

Whether Fin is in this org. The contract, the name on it, and the admin. If there is no contract, stop. Do not design a dual-agent handoff for a product you have not bought. A single agent you already run does not need a fictional partner.

The channel. One, to start. The others stay as they are until this one has a passing test.

The answer rule. Which agent speaks for which kind of request. The person who owns the rule. The case where you are unsure, and who speaks then.

The handoff. What the customer is told. What the next owner receives. What the first agent must not do afterwards. The time you will tolerate silence, and who picks up if it lasts too long. A clock without an owner is a hope.

The log. The transcript, the owner at each turn, and the handoff moment. You will need it when a customer says they were told two different things. If you cannot show one owner, the failure has already happened.

Out of scope. A containment rate. A second sender left on "just in case". A rollout to every Service Cloud org because the acquisition completed. A connector invented to push transcripts into an object you have not named. This page will not name that object. If you need one, it is a separate decision with a field that already exists.

#How the other two pages fit

This page is who answers and how the handoff works. It is not the whole service design, and it is not the press release retold.

What happened to Fin is the close. The day, the former name, and what was not published, including a rate. Send the corporate argument there. Do not let it return as "turn Fin on everywhere".

Fin, formerly Intercom, after the acquisition closed is the build around customers, intents, and the refusal of a universal rollout. Use it when this diagram is accepted and you are scoping a pilot you can stop. A partner who leads with a containment number has skipped both pages. A partner who enables two senders on one conversation has built the failure and will call it coverage.

#A first conversation with one owner

Pick one channel and one kind of request. Confirm, from the contract, whether Fin is even in the estate. If it is not, do not simulate it with a second bot you name Fin for the demo. A renamed bot is not the acquisition. If it is, name the current owner and the handoff owner.

Run five conversations you are allowed to use as tests. Read the transcripts for a second sender after the handoff, and for a stall where nobody answers. Count those defects. Do not convert the count into a containment rate. A count of double replies is allowed. A percentage of "contained" is not, not on this sample, and not as a reason to add a channel.

When the five transcripts each show one owner, and the diagram's three cells match what you saw, you have an integration on that channel. When the transcripts show two voices, turn the second sender off before you widen anything. Width is how the failure reaches customers who did not volunteer for the pilot. The close date will not do this test for you. The date only tells you the companies share an owner. The conversation still needs one.