Integrating Bluebirds with Salesforce

A sales manager draws a list on the left and Sales Cloud on the right. The arrow says Leads. It does not say who owns them, or what happens when the person is already in the org. The room treats the arrow as an integration. It is a poster. An integration names the system, the object, and the failure when the call does not land. The system is prospecting. The object is the Lead. The failure is a second Lead for a person you already have.

Bluebirds is prospecting. Salesforce completed the acquisition on 13 August 2025. Prospecting finds people you might sell to. It does not, on this page, prove that they will buy. This page will not invent a conversion rate. A rate would sound like evidence. The source does not give one, and a borrowed rate from another company would be the wrong rate. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of Bluebirds on August 13, 2025."

#The system is prospecting, not a loaded list

The system decides that a person is worth a Lead, using sources you name. A conference list you already trust. A segment your marketing lead wrote down. A set of accounts you already hold. "The internet" is not a source. A source has an owner in your company and a reason you are allowed to contact the person. If you cannot say the reason, do not create the Lead.

Write the geography, the language, and the product the list is about. A list that mixes countries will create Leads your team cannot work, and it will ignore rules your counsel already set. Those rules are part of the system. An integration that skips them will look productive on a count of new records and expensive on a complaint.

The prospecting step ends when a Lead exists or when a person decides not to create one. It does not end when a slide says pipeline. Pipeline is a later object, an Opportunity, and only after a seller qualifies it. Do not draw an arrow from a name on a list to Closed Won. That arrow is a conversion story this page refuses to number.

Bluebirds and the prospecting quote is where you scope sources and who may create a Lead. This page is the landing rule: one person, one Lead, one owner. What happened to Bluebirds holds the date and the ownership. It does not publish a rate, and neither does this diagram.

#The object is a Lead with an owner

A Lead in Sales Cloud needs an owner. An owner is a person or a queue your sales leader already recognises. A Lead with a blank owner, or an owner that is a generic integration user nobody monitors, has not landed. It has been stored. Storage is not prospecting. Prospecting means someone is accountable for the next step.

Write the fields you will fill. Name. The company. A way to contact them that you are allowed to use. The source. The owner. The status your team already uses for "not yet contacted". Leave blank any field you do not have. A guessed phone number is a defect, not a completion. A guessed title is the same.

The owner has to be able to see the Lead under the sharing you already run. A Lead created in a private corner of the org, visible only to an administrator, will not be worked. The count will rise. The activity will not. Put "owner can open it" on the test. If they cannot, the call did not land.

Do not create a custom object to hold prospects beside the Lead. A second object becomes a second list. Sellers will not live there. You will spend the next quarter reconciling. Use the Lead. If your org has a reasoned exception, name it in the brief as your object. This page will not invent one.

#The failure is a second Lead

You already have this person. They are a Contact on an Account a seller owns. The prospecting run creates a Lead anyway. Now two records claim the same human. The new Lead gets a task. The existing seller is not told. The customer receives two conversations. That is the failure: a second Lead for a person you already have.

A duplicate rule is how Sales Cloud can block or warn. The integration has to name the rule you will use, in the language of your org: which fields must match, and whether a match blocks the create or asks a person. This page will not invent the rule's API name. Your admin either has a rule or does not. If they do not, the first line of the integration is to write one, before any list runs. A list without a rule is a plan to create the second Lead.

Match against Contacts and against open Leads. A match only on Leads will miss the customer you already serve. A match only on email will miss the person who used a second address, and it will also false-match a shared inbox. Write the match you are willing to defend. Imperfection is allowed. Silence is not. Silence means every row becomes a Lead.

When a match is found, the landing is an update a person can see, or no write at all. It is not a new Lead with a note saying possible duplicate. A note nobody reads is a second Lead with a comment. Assign the existing owner, or stop. Do not open a parallel pursuit.

#What the diagram has to show

System: prospecting from sources you named. Object: the Lead, with an owner. Failure: a second Lead for a person you already have. You may show the duplicate rule as a gate before create. You may not show a conversion rate, a connector name, a price, a daily cap, or a current screen. The source does not give them.

Say it without the brand. Prospecting creates or refuses a Lead. The owner can open it. A match does not create another. If the sentence needs a percentage, it is the wrong sentence.

#What you refuse to invent

A conversion rate is the number people will ask for. Do not supply one. Not from memory, not from a benchmark, not from a rounded figure that makes a business case look finished. The business case, if you need one, uses your own history: how your sellers treat a Lead from a source you already run. That history is yours. This page has none to lend.

A connector name would imply a package is the integration. The integration is the rule and the owner. How the row is inserted is a build choice in your org. Name that choice only when your admin has made it. Do not let a brand stand in for the duplicate rule.

A current screen of a prospecting product is a poster. Your sellers need to know which Lead they own on Monday. Draw that. A price and a daily cap are absent from the source. If you limit the pilot to fifty names, that limit is yours, written as a count of the file, not as a product quota.

Do not auto-convert the Lead to a Contact and an Opportunity. Conversion is a seller's decision in your process. An integration that converts on create has skipped qualification and has also made the duplicate problem harder, because the second record is now an Opportunity. Stop at the Lead.

#How you test that the call landed

Build a file of ten people. Five should already exist in the org, as Contacts or Leads, under the match you wrote. Five should be new, and real enough that counsel would allow a test email, or obviously fake if your policy forbids contact. Run the file. Expect five creates and five refusals or five updates. Expect zero second Leads.

Open each new Lead as the owner, not as an administrator. Confirm the source and the status. Confirm a matched person did not gain a twin. Then run the file again. The second run should create nothing new. A second run that creates ten more Leads has no duplicate rule, whatever the diagram claims.

Read the owners' queues. If the Leads are owned by a user the team does not watch, reassign before you call the test passed. An unowned Lead is a landing failure even when the duplicate rule worked.

Keep the first list small enough that a sales leader can read every row. A thousand rows will hide the twin. When the ten-row test is dull, widen the source, not the rules. The rules stay. The source grows only when the owner still sees every create.

A partner who leads with a rate has left the source. Ask them to show the duplicate rule and the owner on one existing Contact. If they cannot, they are not ready to load a list. The implementation page is where that test is priced. This page only insists that you run it before the list is large.

#The person you already serve

Start the match with people who already buy from you. Export a handful of Contacts your sellers would be angry to see duplicated. Include them in the test file under the email or the company name your rule uses. The pass condition is boring. No new Lead. A task on the existing owner, only if you wrote that task down. Silence towards the customer until that owner acts.

Then look at open Leads from last quarter. A prospecting run that recreates them will reset the status a seller already set to unqualified. That reset is a second conversation with someone you decided to leave. The duplicate rule should catch the email. If the new row uses a different email for the same person, the rule you wrote will miss, and you need a second check a person performs on the pilot. Do not pretend the rule is wider than it is.

Write who may turn the run on. A sales leader, not the integration user alone. The first production file should be small enough to read at a desk. When a twin appears, stop the file, delete or merge under your existing process, and fix the rule before the next row. A cleanup project at the end is the failure, deferred. Sellers will have already called the second Lead.

Campaigns and Leads are different objects. If the person should join a campaign you already run, say so as a separate line. Do not let campaign membership create the Lead as a side effect you did not draw. Side effects are how a person you already have becomes a new Lead with a new owner who does not know the history.