How to Connect Strama to Salesforce

Strama connects to Salesforce so the accounts, contacts, and outreach your team works in Strama show up in your org without anyone copying them over. Contacts sync as Salesforce Contacts, companies as Accounts, and the emails and LinkedIn messages Strama sends are logged as activity on the right records.

This guide covers the whole setup: installing the Strama package, connecting your org, configuring how records are matched and updated, mapping owners and fields, verifying data is flowing, and fixing the problems teams most commonly run into.

The Salesforce integration is live. You can connect it from Settings → CRM today.

What syncs between Strama and Salesforce

Four object types move between the two systems.

Outbound messages Strama sends are prefixed [STRAMA] in the subject so you can tell them apart from activity Salesforce logged natively. Inbound replies are not prefixed.

Leads are matched but never created. Strama only ever writes Contacts and Accounts. If a person in Strama already exists in your org as a Lead, Strama links to that Lead rather than creating a competing Contact, and logs activity against it. Lead fields are never modified. You can turn that behavior off (see Lead matching below).

One thing worth knowing before you connect: syncing is not a backfill. Connecting Salesforce does not push your existing Strama database into your org. Records are queued as Strama works them, contacts and companies as they are created, enriched, or edited, and messages as they are sent or received. If you connect and immediately check Salesforce, expect it to be quiet until your team does something. If you want your existing Strama data pushed, ask support and we can queue it for you.

Before you start

On the Salesforce side:

• Your edition needs API access. Enterprise, Unlimited, Performance, and Developer editions have it. Professional Edition requires the API add-on.
• A Salesforce admin has to install the Strama package in the org before anyone can connect. Salesforce blocks the authorization until it is installed.
• The person connecting needs the API Enabled permission, plus read and write access to Contacts and Accounts. Whatever that user cannot see or edit, Strama cannot see or edit either.
• Enhanced Email must be on for email logging. It has been the default since 2016, but it can be switched off. If it is off, email records queue rather than fail, and start flowing the moment it is enabled.
• Person Accounts orgs are not supported yet. Strama detects Person Accounts during the connect and stops before writing anything. Get in touch if you need this.

On the Strama side:

• You must be the team Owner. Connecting, disconnecting, changing sync settings, editing mappings, and triggering syncs are all Owner-only. Other team members can view the CRM settings page but see a read-only version of it.
• There is no plan requirement. The integration is available on every Strama plan.

Step 1: Install the Strama package

Strama's Salesforce app is distributed as a package that has to exist in your org before the OAuth flow will work. Without it, Salesforce rejects the connection with OAUTH_EC_APP_NOT_FOUND.

Go to Settings → CRM in Strama. On the Salesforce tile you will see Step 1 · Install the Strama package with a link to the install page. Flip the Connect to a sandbox org switch first if you are connecting a sandbox, since the install link points at a different Salesforce host for sandboxes.

Open the install page, sign in as a Salesforce admin, and complete the install. This is a one-time step per org.

Step 2: Connect your org

Back on the Salesforce tile, click Connect Salesforce. You will be sent to Salesforce to sign in and approve access, then returned to Strama with the connection live.

Two options on the tile are worth understanding before you click.

Sandbox

The Connect to a sandbox org switch sends the sign-in to test.salesforce.com instead of login.salesforce.com. Connected sandboxes are labeled with a Sandbox pill on the connection card so nobody mistakes one for production.

My Domain

The optional My Domain field only matters if your org blocks sign-in on login.salesforce.com, which many orgs do. In that case your session and credentials only exist on your own Salesforce host, and the whole OAuth flow has to run there.

Enter the bare host, for example acme.my.salesforce.com. Sandboxes look like acme--dev.sandbox.my.salesforce.com. Pasting the full URL out of your browser bar is fine, Strama reduces it to the host. Anything that is not a .my.salesforce.com host is rejected with an explanation rather than silently ignored.

Leave the field blank to use Salesforce's standard login page.

Once connected, the page shows your org ID and instance host, who connected it, and a health strip with counts of companies, contacts, and messages synced, plus when the last sync ran.

What Strama asks permission for

Salesforce grants access as broad scopes rather than per-object permissions, so the list is short.

What actually bounds Strama's access is the permissions of the Salesforce user who connects. Strama can only touch what that user can touch. If you want the integration confined to specific objects or fields, do it with that user's profile or permission set.

One consequence worth planning for: records Strama creates are owned by the connecting Salesforce user. Owner mapping (Step 4) drives which user logged activity is attributed to, not who owns the Contact or Account record. If record ownership matters in your reporting, connect with a user you are happy to see as the owner, or reassign after the fact.

Step 3: Configure sync behavior

The Sync behavior card has six settings for Salesforce connections. Changes save automatically and apply to your whole team.

Sync mode

Create only (the default) or Create & update.

On Create only, Strama will create records that do not exist in your org but will never write to ones that do. If Strama matches a Contact you already have, it adopts that record as-is and leaves every field alone, your job titles, your data.

On Create & update, Strama also pushes its values onto matched records, overwriting what is there.

Several protections apply either way. Strama never writes an empty value, so a blank field in Strama cannot wipe a populated one in Salesforce. It never overwrites a Contact's Email or an Account's Website, because those are the fields that decide which record something actually is. It only fills a Contact's AccountId when it is currently empty, so an existing primary account association is never displaced. And Account names are left alone on any record that was matched loosely rather than on an exact domain.

Company matching

By domain (the default) or By name. Before creating an Account, Strama looks for an existing one that matches.

Domain matching compares against the Account Website field, parsed as a real URL so acme.com never matches notacme.com.au. It also checks the corporate email domains of the company's contacts, so app.acme.com and acme.com do not become two records. For a loose match like that to be accepted, the company names have to be similar too. When several Strama companies resolve to the same Account, one write covers all of them.

Company name fallback

On (the default) or Off. Salesforce-only, and only shown when you are matching by domain.

Plenty of real Salesforce orgs have Accounts with no Website filled in. Those are invisible to domain matching, so without this setting Strama would create a duplicate next to an account you already had. With it on, unmatched companies get one more pass: an exact, case-insensitive name match. Matches found this way are adopted without renaming the account.

Turn it off if your org has many similarly named accounts and you would rather have a duplicate than a wrong link.

Duplicate contacts

Delete Strama's copy (the default) or Keep both.

Sometimes a contact syncs before Strama has finished enriching their email address, and the address turns out to belong to someone already in your org. When that happens, Strama re-points to the existing Contact and moves any activity it logged onto that record. This setting controls what happens to the extra record Strama created, delete it or keep both.

Strama only ever removes a record it created itself. Contacts that were already in your org are never deleted.

Lead matching

Link as contact (the default) or Block. Salesforce-only.

People your team is prospecting often already exist in the org as unconverted Leads. On Link as contact, Strama matches those by email, links to the Lead, and logs emails and LinkedIn Tasks against it. No competing Contact is created, and nothing on the Lead is ever written. Converted leads are skipped, since their Contact counterpart is matched normally.

On Block, a lead-only match is not synced at all. The record shows up as failed with a readable reason, so someone can convert or remove the Lead first. Choose this if your process depends on Leads and Contacts staying strictly separate.

Inbound email logging

Off, Managed inboxes (the default), or All.

This controls whether replies landing in Strama get logged to Salesforce. Managed inboxes logs replies to the inboxes Strama provisioned, matching the outbound behavior. All logs every inbound email from a matched contact.

Unlike HubSpot, Salesforce connections can safely use All. Every email Strama logs carries its Message-ID, and Strama checks for that ID in your org before writing, so a message Einstein Activity Capture or a Salesforce-connected mailbox already logged is not written a second time.

Step 4: Map owners

The Owner mapping card lists your Strama team members alongside a Salesforce user. Click Edit mappings to load the user list from your org and pair them up. The list covers active standard users.

Mapping drives activity attribution: the LinkedIn Task's owner, and the sender relation on logged emails. Mapping is optional, and unmapped members still sync normally. Their activity just lands owned by the connecting user rather than the rep who did the work, so it will not roll up correctly in Salesforce reporting. If you care about attribution, do this before you start sending.

Step 5: Review field mappings

The Field mapping card has two sections, Contact fields and Company fields, each showing which Salesforce field every Strama field writes to.

The defaults:

There is no Timezone row. Salesforce Contact has no standard timezone field, so Strama does not map one.

LinkedIn URLs

Salesforce has no standard LinkedIn field, and custom fields cannot be created through the API, so Strama does not create one. Instead, at connect time it looks for a writable custom field that already exists, checking LinkedIn_URL__c, LinkedIn__c, LinkedInUrl__c, and LinkedIn_Profile__c in that order, then any other writable field whose name or label mentions LinkedIn, preferring one typed as a URL. It does this for both Contact and Account.

If your org has none, the mapping is skipped, the Field mapping card says so, and LinkedIn-based contact matching is unavailable. To turn it on, have an admin create a URL field on Contact (for example LinkedIn_URL__c), grant field-level access to the relevant profiles, then re-authenticate from the connection card so Strama re-detects it.

Field-level security matters here: a field the connecting user cannot see does not exist as far as Strama is concerned.

Strama writes LinkedIn URLs as https://linkedin.com/in/username and https://linkedin.com/company/name, and matches contacts by comparing that string exactly. If your org stores URLs in a different shape, with a www. prefix for instance, those records will not match and Strama will treat them as new.

Editing a mapping

Unlike the HubSpot version of this card, Salesforce field names are picked from a searchable list loaded live from your org, covering fields that are both createable and updateable for the connecting user. A mapping pointing at something that is not in that list is flagged with a warning. Reset to defaults restores the standard mappings and re-detects your LinkedIn field.

How syncing works

Strama processes the sync queue every five minutes, handling up to 100 records per object type each run. A large first batch will trickle through over several cycles rather than landing all at once. Companies drain first, since a contact waits for its account to exist before it syncs.

To push what is pending immediately, use Sync now at the bottom of the CRM settings page. It drains the queue on demand and does not re-push records that already synced.

Strama watches your org's daily API allocation and stops the sync cycle if it would push usage past 90 percent. Records stay queued and resume on the next cycle. In practice a full 100-record cycle costs single-digit API calls per object type, so this is a guardrail rather than something you should expect to hit.

Importing from Salesforce

Sync is not the only direction. When adding contacts in Strama, choose your CRM as the source and you can import from a Salesforce contact list view. Any list view on Contact that the connecting user can see is available. Contacts you import that already exist in your org are linked to their existing records rather than duplicated.

Company search works the same way: searching for a company in Strama searches your Accounts by name, returning name, website, industry, and LinkedIn URL where it is mapped.

Verifying the connection

Three places tell you whether things are working.

• The health strip on the connection card, with counts of companies, contacts, and messages synced, anything pending or failed, and the time of the last sync.
• The Sync status card, with per-object tiles for Companies, Contacts, Emails, and LinkedIn Messages, plus a table of any failed records showing Salesforce's own error message.
• Salesforce itself. Open a Contact your team has worked recently. Emails Strama sent appear on the activity timeline with the [STRAMA] prefix, and on the related Account's timeline too. LinkedIn messages appear as completed Tasks titled [STRAMA] LinkedIn message, dated to the day the message was sent.

Troubleshooting

"The Strama package isn't installed in this Salesforce org yet"

Salesforce rejected the authorization with OAUTH_EC_APP_NOT_FOUND. The install in Step 1 has not been done, or was done in a different org than the one you signed into. The error screen carries install links for both production and sandbox. Note that a sandbox needs its own install, a production install does not carry across.

The connect screen reports an invalid My Domain host

The value has to be a bare Salesforce My Domain host ending in .my.salesforce.com. For example acme.my.salesforce.com, or acme--dev.sandbox.my.salesforce.com for a sandbox. Copy it out of your browser bar while signed into Salesforce, or leave the field blank entirely and use the standard login page.

Emails are not appearing on timelines

Almost always Enhanced Email being off in the org. Strama checks for it before writing and, when it is missing, leaves the email records queued rather than failing them. Have an admin enable Enhanced Email in Setup and the backlog logs on the next cycle with nothing to re-queue.

If Enhanced Email is on and emails are still missing, check that the contact has a matched Salesforce Contact. Emails are logged against the contact record, so a contact that has not synced yet has nothing to attach to.

An Account was created that already existed

Usually the existing Account has no Website filled in, which makes it invisible to domain matching. Keep Company name fallback on, which catches exactly this case with an exact name match. Filling in Website on your accounts is the durable fix.

The other cause is a bad website value in Strama. Link shorteners and social URLs are ignored rather than used as a match key, but if a company's website in Strama is not its real site, matching has nothing good to work with.

A contact linked to a Lead instead of a Contact

That is Lead matching on Link as contact doing its job: the person exists in your org as an unconverted Lead, and Strama linked to it rather than creating a duplicate Contact alongside. Activity logs against the Lead. The sync record notes the match. If you would rather these fail loudly so someone converts the Lead first, switch Lead matching to Block.

A record failed with a duplicate rule error

Active duplicate rules set to Block will reject Strama's creates. In most cases Strama reads the matched record out of the rejection and adopts it, which is the outcome you want, and the record ends up linked rather than failed. It only surfaces as a failure when the match is something Strama cannot adopt, such as a Lead while Lead matching is set to Block.

A contact failed for a missing last name

LastName is required on Salesforce Contact and Strama will not invent a placeholder. Fill in the last name in Strama and the record syncs on the next cycle. Existing contacts Strama adopts are unaffected, since adoption does not write the name.

Authorization expired

A red banner appears and syncing pauses, queueing records rather than dropping them. The team Owner clicks Re-authenticate and signs in again. It must be the same org. The queue resumes once the connection is restored.

Individual records failed

Failed records are retried automatically five times with backoff before landing in the failed records table, where each row shows Salesforce's error message and a Retry button. Retry all failed re-queues the whole table at once. The error text usually names the problem directly: a validation rule, a required field, or field-level security on the connecting user's profile.

Validation rules are the most common surprise. Strama sends the fields you mapped and nothing else, so a rule requiring a field Strama does not populate will reject every create. Either map that field or exempt the integration user.

Disconnecting Salesforce

Go to Settings → CRM and click Disconnect on the connection card. Syncing stops immediately.

Nothing is deleted from Salesforce. Records Strama already created or updated stay exactly as they are, and your Strama contacts and companies are untouched. What gets cleared is the queue, anything still pending or failed is dropped.

Records that synced successfully keep their Salesforce ID, so reconnecting the same org picks up where you left off. Connecting a different org, or switching to HubSpot, resets field mappings, owner mappings, and sync history.

Getting help

Email support@strama.ai with your org ID, which is on the connection card, and we will take a look.

Not using Strama yet? Take a look at what it does.