Skip to main content
Tightknit’s Salesforce integration connects community activity directly to the deal cycle. Track your contacts’ engagement in your community, sync new community activity, and measure how involved your Accounts are in your customer workspaces, all from Salesforce.

Overview

What the integration does, how syncing works, and the Salesforce data model.

Setup guide

Install the managed package and connect your org, step by step.

Customization

Add Lightning components to your record pages and manage permission sets.

Troubleshooting

Diagnose and fix common setup, connection, and sync errors.

​
Overview

​
Key capabilities

For Account Executives & CSMs

  • See engagement for any Contact or Lead. View the communities they’ve joined and how active they are.
  • Analyze engagement by Account. Aggregate activity across every associated Contact, and report on it by deal value.

For Community Managers

  • Prove the community’s impact. Compare deal performance across engagement levels to show how community drives revenue.

​
How it works

The integration consists of two parts: a Salesforce Managed Package installed in your Salesforce org, and a connection configured in the Tightknit Admin Studio. Once the integration is enabled, Tightknit pushes community and member profile data to Salesforce, populating custom Tightknit Community and Community Member records. It also begins a periodic sync of all new community activity, creating Community Activity records in Salesforce.
  • Records are pushed using the Bulk API 2.0.
  • Activity syncs run every 5 minutes, batching all new activity within that interval.
  • Members are linked to Contacts and Leads by email matching. Linking is not affected by the creation setting below: the sync links every member it can match on either object. Lead linking additionally requires managed package v1.13+ and Lead Read for the integration user. You can manually override any incorrect links.
  • Members with no match can get a new record created for them. The Create Contacts or Leads setting controls whether the sync creates nothing, a new Contact, or a new Lead. Contact and Lead are handled independently, so a member who already matches a Contact still gets a Lead when the setting is Leads.
  • Members whose email is longer than 80 characters aren’t synced. Salesforce email fields hold at most 80 characters, so these members and their activity are skipped, and the sync job shows a warning with how many.
  • An initial backfill sync imports your existing historical data when you first enable the integration.

​
Data model

The managed package includes three custom objects in a simple parent-child hierarchy, plus configurable lookups that link each member to a standard Salesforce Contact or Lead:
Once the managed package is installed, these objects carry the package namespace prefix. For example, Community__c appears as tightknit__Community__c in reports, list views, and SOQL.
The managed package also includes pre-built Lightning Web Components (LWCs) that surface this data on Salesforce record pages, plus permission sets that control who can see it. See LWC components and Permission sets below.

​
Setup

Complete these steps once, in order, to install the managed package, connect your Salesforce org to Tightknit, and start syncing community data.

​
Before you begin

Plan who will do the setup, and how they will connect. Completing the connection requires a real, interactive Salesforce login, which determines who can do it and which configurations are supported:
  • The user setting up the connection within the Tightknit Studio must be able to log into Salesforce using the integration user’s real credentials. Salesforce’s “Login As” feature does not work for this. OAuth authorization is blocked inside an impersonation session and fails with Insufficient Privileges.
  • The integration user needs a UI-login-capable license. The free Salesforce Integration license is API-Only (no UI login) and cannot complete the connection. Use a Salesforce Platform license or a standard Sales/Service Cloud seat, kept least-privilege with the Tightknit permission sets.
  • Connect a production org, not a sandbox. Sandbox orgs are not supported.

​
Install the managed package

Salesforce sandbox orgs are not supported. The OAuth flow from the Tightknit Studio does not work with sandbox orgs. Connect a production org instead. See Known issues.
Install the Tightknit Analytics managed package using one of the following methods:
Open the installation link and follow the prompts. We recommend installing the package for Admins only.Install
Salesforce managed package install screen with Install for Admins Only selected
We recommend choosing Install for Admins Only. It is the safest option and the Salesforce-recommended default, since it limits initial access to system administrators while you finish configuring the integration. Once setup is complete, you can grant access to other users by assigning them the Tightknit permission sets.
If your org uses a custom domain, use this URL format instead: https://<domain>.my.salesforce.com/packaging/installPackage.apexp?p0=04tdM000000d1aXQAQ

​
Prepare Salesforce

New to Salesforce administration? Read this first. The steps below lean on a few Salesforce terms. Here is what each one means in plain language:
  • Integration user — a dedicated Salesforce user account that Tightknit signs in with to sync data, instead of using a real person’s account. Think of it as a robot account.
  • Permission set — a switchable bundle of permissions you assign to a user. Salesforce starts locked down, and permission sets are how you hand out exactly the access something needs. Tightknit ships ready-made ones, so you assign rather than build them.
  • License — the type of seat a user occupies. It caps what that user can do, and a permission set can only switch on access the license already allows.
  • External Client App — the pre-built component that lets Tightknit sign in to your org securely (the OAuth handshake).
You do all of this once, during setup. The steps below walk through each piece in order.
1

Assign yourself the Tightknit Admin permission set

Right after installing, you may not see the Tightknit app in Salesforce yet, not even as an administrator. That’s expected. Salesforce keeps an installed package’s apps hidden until you give your own user the package’s Tightknit Admin permission set. (This is a Salesforce rule: an installed package can only reveal its apps through a permission set, so everyone, admins included, has to assign it. There is no way around it from the admin profile.)To assign it to yourself:
  1. In Salesforce, go to Setup. In the Quick Find search box, type Permission Sets and click it.
  2. Click Tightknit Admin in the list.
  3. Click Manage Assignments, then Add Assignment.
  4. Check the box next to your own user, click Next, then click Assign.
Now refresh the App Launcher (or sign out and back in) so the new access takes effect.
2

Open the Setup tab in the Tightknit app

Launch the Tightknit app from the Salesforce App Launcher, then open the Tightknit Setup tab in its navigation bar.
Salesforce App Launcher with Tightknit typed into the search field and the Tightknit app highlighted in the Apps list

Search for Tightknit in the App Launcher and select the Tightknit app. Setup lives on its Tightknit Setup tab.

On earlier package versions, Setup and Health Check live in a separate Tightknit Setup app in the App Launcher instead of a tab. Upgrading to the latest package version moves them into the main Tightknit app.
3

Run the setup wizard to create your integration user

On the Tightknit Setup tab, the wizard walks you through picking the Salesforce user that the sync will run as and assigning it the Tightknit Integration User permission set. We recommend creating a brand-new, dedicated Salesforce user for Tightknit rather than reusing a real person’s account. A dedicated user keeps the sync running no matter who joins or leaves your team, and makes its activity easy to spot in your logs.No spare license, or cannot create a user? Use your own user. Assign the Tightknit Integration User permission set to yourself in the wizard and the sync runs as you. The trade-off is that the sync depends on your account staying active, so if you leave the team or your access changes, syncing stops until someone assigns the permission set to another user.The wizard’s later steps cover granting Contact and Lead access and giving the rest of your team access with the Tightknit Admin, Tightknit Read Only, and Tightknit Users permission sets.
Which license should the integration user have? Use a Salesforce Platform license or a standard Sales Cloud or Service Cloud seat.Avoid the free Salesforce Integration license for this user. It is API-only and blocks UI login, which can cause the OAuth sign-in to fail when you connect the user from the Tightknit Studio. That license is built for a server-to-server (client-credentials) flow that this integration does not use; supporting a server-to-server connection with no interactive login is a known gap we are tracking as a future improvement.
4

Grant the integration user access to Contacts and Leads

The Tightknit sync matches your community members to existing Salesforce Contacts and Leads by email, so the integration user needs permission to read both objects. Lead matching requires managed package v1.13+. The Tightknit Integration User permission set does not include this access, and it can’t: Salesforce blocks any installed package from handing out access to standard objects like Contact, Account, and Lead. So this one is on you to grant separately.Give the integration user Read on Contact and Lead. Lead Read lets the sync link members to existing Leads whatever the creation setting. Add Create on Contact only if you set Create Contacts or Leads to Contacts, or add Create on Lead only for Leads. Pick whichever way fits how your org is set up:If Tightknit creates Contacts or Leads, the integration user must also see every record of the object it creates: grant View All Records on Contact (for Contacts) or Lead (for Leads), or make that object’s org-wide default Public Read Only. The sync looks for an existing record by email before creating one, but only among the records the integration user can see, so a record hidden by sharing would be created again as a duplicate.Tightknit checks this before it creates anything, and treats “can’t tell” as “no”:
  • The object’s org-wide default is Public Read Only or wider. The integration user sees every record, so creation is allowed. Nothing else is needed.
  • The default is private. Tightknit reads the integration user’s permission assignments to confirm View All Records (or View All Data). Reading them needs View Setup and Configuration, so grant that too. If Tightknit can’t read the assignments, it can’t rule out hidden records, and creation stays off.
  • Salesforce doesn’t return the org’s sharing settings at all. Tightknit creates nothing that time. This is usually temporary: Studio asks you to try again, and the sync tries again on its next run.
Tightknit Studio runs this check before it enables a creation option, and each sync runs it again before creating anything. If sharing later hides records, or you reconnect as a user with less access, the sync creates nothing and reports why in Sync History.
  1. Add a minimal extra permission set (recommended). Create a new permission set, grant the object access described above, and assign it to the integration user alongside the Tightknit one. This is the cleanest option because it adds access without touching anything else, and survives package upgrades.
  2. Edit the integration user’s profile. Open the profile the integration user is on and grant the same object access there.
Don’t assume the integration user already has Contact access and skip this. Whether it does depends on the user’s license and profile, and a dedicated integration user often has neither. If Contact access is missing, the sync fails until you grant it. You don’t have to check by hand, though: the Health Check on the Tightknit Setup tab and Tightknit Studio’s connection test both flag missing Contact access before you start the sync.
5

Configure the External Client App OAuth policies

The package ships an External Client App named Tightknit Salesforce that handles the secure OAuth sign-in. Set its policies before connecting:
  1. Go to Setup, and in Quick Find open External Client App Manager.
  2. Click Tightknit Salesforce, open the Policies tab, and click Edit.
  3. Under OAuth Policies:
    • Permitted Users: “Admin approved users are pre-authorized” (recommended), so only users you authorize can connect. You can choose “All users may self-authorize” instead, but it is less restrictive.
    • Refresh Token Policy: “Refresh token is valid until revoked”, so the connection doesn’t expire on its own.
    • IP Relaxation: “Relax IP restrictions” unless your security team requires otherwise.
  4. Click Manage Permission Sets and add Tightknit Integration User (plus Tightknit Admin if the integration user is also an admin). This authorizes the integration user under the “Admin approved” policy. Skipping it is the most common setup mistake and causes the connection to fail (OAUTH_APP_ACCESS_DENIED, “user is not admin approved to access this app”, or OAUTH_APPROVAL_ERROR_GENERIC).
  5. Save.
6

Assign the Tightknit Users permission set group to end users (optional)

If you want other users in your org to see the Tightknit Lightning Web Components on Contact, Account, and other record pages, assign them the Tightknit Users permission set group. This group contains Tightknit Read Only and is the recommended way to grant end-user access. See Permission set group for details.You can do this now or after the sync is running. Without this assignment, the components render an empty state for users who lack the necessary object access.
7

Run the Health Check (optional but recommended)

On the Tightknit Setup tab, open Health Check. It verifies that the managed package’s Org-Wide Default sharing settings let everyone in your org see synced data, with a “Fix in Setup” deep link for any check that needs attention.
Tightknit Health Check showing three OWD checks: Community Activity (Action Required, default internal access is Private), Community Member (Healthy), and Tightknit Community (Healthy). The Action Required row has a Fix in Setup button.

The Health Check on the Tightknit Setup tab flags any Org-Wide Default sharing setting that would hide synced data from other users in the org. Each finding has a Fix in Setup button that opens the relevant Sharing Settings page in a new tab.

Click Fix in Setup on any flagged row to open the relevant Sharing Settings page in a new browser tab, apply the recommended setting, then click Refresh on the Health Check to re-verify. The Health Check is non-blocking: you can connect Tightknit and start syncing without resolving every finding, but unresolved findings may mean some users in your org won’t see the synced data.

​
Grant Studio access

If your Salesforce administrator is not already a Studio user, you need to invite them and assign the Integrations Manager role so they can manage the Salesforce connection.
1

Invite the user

Navigate to Settings > Workspace and invite your IT admin via their email address.
The email used for the invitation must exactly match the email associated with their Slack profile. If the emails don’t match, the user will be unable to log in.
2

Assign the Integrations Manager role

Once the user has been added, assign them the Integrations Manager role. This grants access to manage integration settings (including Salesforce), webhooks, and API keys, without exposing other administrative areas of the Studio.
For more details on Studio access and available roles, see Access the Studio.

​
Connect in Tightknit

1

Open the Salesforce integration settings

Navigate to Integrations > Salesforce in the Tightknit Admin Studio.
Salesforce integration settings page in the Studio with Salesforce highlighted in the sidebar and the Connect button highlighted

Salesforce integration settings page with the Connect button.

2

Connect to Salesforce from the Tightknit App

Connect to your Salesforce org. In a separate browser tab, log in to Salesforce with the integration user’s own credentials (a real login, not “Login As”; see Before you begin). Then return here and click Connect to authorize. The Salesforce user that is logged in when the connection is authorized will be treated as the integration user for the Tightknit sync going forward.Verify the managed package. Click the Verify Managed Package button to confirm the package is correctly installed in Salesforce.

​
Start the sync

After connecting your Salesforce org, the settings page presents a three-step timeline wizard: Connect, Configure, and Backfill. You can adjust every sync option before starting the sync for the first time.
1

Connect

Complete the Salesforce OAuth connection as described above. Once connected, this step is marked complete and the Configure step becomes active.
2

Configure sync settings

Set your preferred sync options before starting the sync. Available settings include:
  • Create Contacts or Leads — whether Tightknit creates a Salesforce record for members who don’t have one yet. It never affects linking: every sync links members to any Contact that matches their email, and to any unconverted Lead once the managed package is on v1.13 and the integration user can read Leads, whichever option you pick. The setting only decides what gets created when there’s no match, and on which object. The setting applies to all members, not just new ones. Members who were already in your community are worked through a few hundred per sync, so a large community can take several syncs to finish. To do it all at once, use Run backfill again on the Initial backfill step in Studio.
    • None — Tightknit creates no Contacts or Leads. Members with no match sync unlinked, and members that match a Contact or unconverted Lead are still linked.
    • Contacts — Tightknit creates a Contact for each member whose email doesn’t match an existing Contact. Requires Create on Contact for the integration user.
    • Leads — Tightknit creates a Lead for each member whose email doesn’t match an unconverted Lead, even if the member already has a Contact. Leads have looser validation than Contacts, so this suits orgs whose validation rules block Contact creation, and it lets you clean up the data before converting a Lead to a Contact. Requires managed package v1.13+ and Read and Create on Lead for the integration user.
      • Members that already match an unconverted Lead are linked to it instead of getting a duplicate.
      • A member whose only Lead was already converted gets no new Lead and no Lead link, since their live record is the Contact.
      • Salesforce requires a Company on every Lead and Tightknit profiles don’t have one, so created Leads use [not provided].
      Members who already have a Contact still get a Lead, so a duplicate rule set to Block Leads that match an existing Contact will reject those Leads. The sync still completes, and those members sync without a Lead link. The rejections appear in the sync job’s failure log and aren’t retried by later incremental syncs. After you relax the rule, use Run backfill again in Studio to retry them.
    Switching options later keeps what you already have. Records Tightknit created stay in Salesforce, and existing links stay in place, because every sync matches against both objects whichever option is selected. Moving from Leads to Contacts doesn’t unlink anyone’s Lead, and moving to None leaves every link in place. Moving from Contacts to Leads gives a new Lead to every member without one, including members who already have a Contact, so those people end up with both a Contact and a Lead. Only what gets created changes, and the new option works through existing members over the following syncs, as described above.
  • Lead source — an optional value Tightknit puts in the standard Lead Source field of every Lead it creates. Studio asks for it when you choose Leads, starting from any value you saved before, so even the first Leads get it. You can change it later in the field under the setting; a change applies only to Leads created afterward. Use one of your Lead Source options in Salesforce. If your org only accepts the options on its list (a restricted picklist), any other value would get every Lead rejected, so Studio checks the value before saving it.
  • Member matching field — how Tightknit finds a member’s Contact or Lead. It’s always Email, and read-only.
  • Activity Metadata — include additional metadata fields on synced Activity records.
  • Sync interval — how frequently incremental syncs run (for example, every 5 minutes).
You can change these settings at any time, even after the initial sync is running.
3

Review and start the sync

Click Start Sync to open the review dialog. The dialog displays your chosen configuration and asks you to verify the Managed Package installation. Once verified, confirm to activate the integration and begin the initial backfill in a single step.The backfill imports your existing historical data and may take several minutes depending on the size of your community. Progress is displayed on the page and refreshes automatically.
Once the backfill completes, the incremental sync runs automatically at your configured interval. All three steps are marked complete, and a pause/resume toggle appears so you can temporarily suspend syncing without disconnecting.
To view your Salesforce sync history, click the Sync History tab at the top of the Salesforce integration settings page.

​
Manage the integration

The Salesforce integration page in Studio

The Salesforce integration page in Studio

​
Monitor sync history

The Sync History tab shows a log of every sync job (backfill and incremental) with explicit counts of succeeded and failed records. Expand any row to see a summary of that sync run. Investigating failed sync jobs. When a sync job has failures, the expanded row shows an Investigate button. Clicking it opens a detail page with:
  • A summary of the sync job (status, timing, record counts).
  • A breakdown of the underlying Salesforce Bulk API jobs, showing per-object totals for processed, succeeded, and failed records.
  • Record failures, such as Contacts or Leads Salesforce refused to create, each linked to the member it belongs to.
Use this view to identify which objects or records failed and why. The most common causes are permission gaps on the integration user (see Troubleshooting below) and Salesforce validation rules rejecting specific records. With Lead creation enabled, also watch for Lead duplicate rules and a restricted Lead Source picklist rejecting the configured Lead source value.

​
Disconnect

Disconnecting requires two separate actions in the Studio: one to tear down the integration connection, and one to revoke the underlying Salesforce OAuth account.
1

Disconnect the integration connection

Navigate to Integrations > Salesforce and scroll to the Connection section. Click the ··· overflow menu to the right of Connection and select Disconnect. This reveals the connection widget below.
Salesforce connection settings with the Disconnect option highlighted in the overflow menu

Overflow menu next to the Connection heading: select Disconnect.

2

Disconnect the Salesforce account

On the newly revealed connection widget, click the ··· overflow menu next to the connection status and select Disconnect account. This revokes the OAuth authorization to your Salesforce org.
Connection widget with Disconnect account option highlighted in the overflow menu

Overflow menu on the connection widget: select Disconnect account.

3

Refresh the page

Click the refresh button next to the connection widget to confirm the disconnection and update the page state.

​
Additional customization

​
LWC components

The managed package includes custom Lightning Web Components that surface community data on your Salesforce records. On the Tightknit objects, this is already done. The Tightknit Community, Community Member, and Community Activity record pages ship configured, so those components appear as soon as the package is installed. On Account, Contact, and Lead, you add them yourself. Salesforce does not let an installed package change your Account, Contact, and Lead pages, so those are up to you. Open a record, choose Setup menu › Edit Page, drag the component from the left-hand list onto the layout, then Save and Activation. The package also ships sample Account, Contact, and Lead pages you can copy from. We recommend exploring the following components:

​
Component previews

Select a component to see it in action. Click any image to view it at full size.
Account Community Activity Summary LWC showing contacts who are members and their activity counts

Community activity for contacts associated with an Account, with per-contact activity counts.

Permissions required to view LWC components. Object Read alone is not enough: the components call Apex controllers that enforce field-level security, so a viewing user needs Apex class access, field-level read, and record visibility together. Assign the Tightknit Users permission set group (which contains Tightknit Read Only) to any user who should see the components. See Permission sets below.

​
Permission sets

The Tightknit package ships three permission sets, each aimed at a different kind of user. Each bundles the full access that user needs, so you don’t have to assign individual permissions. To assign any of them: go to Setup → Permission Sets, click the set, click Manage Assignments → Add Assignment, pick the users, and click Assign. Here’s who gets which one:
These permission sets grant access only to Tightknit’s own objects and components. They do not grant access to your Contacts, Accounts, or Leads. The components show only the contacts and accounts a user can already see through their own profile and your org’s sharing settings, so assigning Tightknit Read Only never widens a user’s access to your CRM data.

​
Permission set group

The package also ships a Tightknit Users permission set group. A permission set group bundles permission sets into a single assignable unit: you assign the group to a user and they receive the combined access of every set inside it. Tightknit Users currently contains Tightknit Read Only, and it is the recommended way to grant end-user access. Assign the group instead of the underlying permission set: when future versions add new end-user capabilities to the group, everyone already assigned picks them up automatically, with no re-assignment needed.
Giving all users access. To let everyone in your org see the components, assign the Tightknit Users permission set group to all users. You can multi-select on the Manage Assignments screen, bulk-assign with Data Loader, or auto-assign new users with a record-triggered Flow on the User object. Avoid assigning Tightknit Admin broadly; it grants Setup access that most users don’t need.

​
Building your own integration user permission set (advanced)

Most people can skip this section. Assigning the ready-made Tightknit Integration User permission set to your integration user is all the sync needs, and it picks up new Tightknit fields automatically every time you upgrade the package. Only keep reading if you have a specific reason to build a custom permission set yourself.
You might build your own permission set if, for example, you want to combine the access for several integrations into one set, or match your org’s naming conventions. If so, the rest of this section lists exactly the access the sync requires. The easiest approach is to open the packaged Tightknit Integration User permission set as a reference and copy its grants into yours. System permissions
  • ApiEnabled — the OAuth token can’t make API calls without it. Required even on profiles that already have API access, so the integration user works on restricted profiles like Minimum Access - Salesforce or the Salesforce Integration license.
Standard object access
  • Contact: Read — the sync queries Contacts by email to link Tightknit members to existing CRM Contacts, and the Member__c.Contact__c lookup field needs the target object to be readable in the user’s schema.
  • Contact: Create — also required if you set Create Contacts or Leads to Contacts in Start the sync. Without that, Read alone is sufficient.
  • Lead: Read — required to link members to existing Leads at all, in every creation mode. It lets the sync match unconverted Leads by email and resolve the Member__c.Lead__c lookup (package v1.13+). Without it, Lead linking is silently skipped.
  • Lead: Create — also required when Create Contacts or Leads is set to Leads. Without that, Read alone is sufficient.
  • Contact or Lead: View All Records — required on the object a creation option creates, unless its org-wide default is Public Read Only. Email matching only sees records the integration user can see, so records hidden by sharing would be created again.
  • View Setup and Configuration: required alongside View All Records when that object’s org-wide default is private, so Tightknit can read the user’s permission assignments and confirm the grant. Without it, a creation option stays off on a private object.
Tightknit custom object access On each of Community__c, Member__c, and Activity__c, grant: Create, Read, Edit, Delete, View All Records, and Modify All Records. Standard CRUD lets the sync upsert records. Modify All Records is required because Bulk V2 upserts return INSUFFICIENT_ACCESS_OR_READONLY in orgs with Private OWDs or when record ownership has been reassigned away from the integration user. It is the easiest grant to overlook and the most common cause of sync failures on a hand-rolled permset. Field-level security on the Tightknit custom objects Grant Read + Edit on every field the sync writes across the three Tightknit objects. The cleanest approach is to grant Read + Edit on all custom fields on Community__c, Member__c, and Activity__c. That keeps your permset correct across package upgrades without per-version edits.
The easiest fields to miss: Member__c.Contact__c and Member__c.Lead__c. These are lookup fields pointing at standard objects, and admins commonly skip over them when granting field-level security, partly because lookups feel like they should be governed by the target object’s access alone. They aren’t: each lookup field on Member__c needs its own FLS grant. Missing one produces a Field name not found Bulk V2 error that looks like a missing field rather than a permissions gap. (Lead__c exists only on package v1.13+; the sync detects the field automatically and includes it whenever your org has it, in every creation mode.)

​
Troubleshooting

Assign the Tightknit Admin permission set to your user (Setup → Permission Sets → Tightknit Admin → Manage Assignments), then refresh the App Launcher or sign out and back in. Managed packages can only grant Lightning app visibility through permission sets, so even system administrators need this assignment.
For tightknit__Contact__c: the integration user can’t see the standard Contact object, so the Member__c.Contact__c lookup is unresolvable. The Tightknit permission set cannot grant access to standard objects (a Salesforce platform limitation), so this must be granted separately. Grant the integration user Read on Contact (see Grant the integration user access to Contacts and Leads). Add Create as well if you set Create Contacts or Leads to Contacts.For tightknit__Lead__c: the sync detects this field before each run and omits the column when the org lacks it, so an older package or missing Lead access does not produce this error; it turns Lead linking off instead. The error means access was removed after a successful check, inside the hour that result is cached. Restore field-level Read and Edit on Member__c.Lead__c (and Read on Lead) for the integration user; the sync recovers on its own once the cached check expires, within an hour.
Open the sync job’s Investigate view in Sync History to see the per-record errors. The common causes:
  • Missing Lead access. The integration user needs Read and Create on the Lead object, including the Email, Name, and Company fields. Studio won’t let you choose Leads until this is granted, but access can regress afterwards.
  • Lead validation or duplicate rules. Org validation rules and duplicate rules apply to Leads the sync creates. A common case is a duplicate rule set to Block Leads matching an existing Contact, which rejects every member who already has a Contact. The failed records appear in the sync job’s failure log with the Salesforce error; the affected members still sync, just without a Lead link. Rejected members are not retried on later incremental syncs; once the rule is relaxed, use Run backfill again in Studio. Failures Salesforce does not attribute to a rule, such as an error in your own automation, are retried automatically about once a day.
  • Restricted Lead Source picklist. Studio checks the configured Lead source against the picklist when you save it. If the picklist changes afterwards so the value is no longer active, the sync stops before creating any Lead and the sync job says so. Change the value in Studio or add it to the picklist.
That object’s org-wide default is private, so Tightknit has to confirm the integration user can see every record before creating any, and it couldn’t. It reads the user’s permission assignments to find View All Records or View All Data, which needs View Setup and Configuration. Grant the integration user View Setup and Configuration together with View All Records on the object, or make the object’s org-wide default Public Read Only, then choose the option again. If Studio instead says it couldn’t read your org’s sharing settings, that is usually a temporary Salesforce error; try again in a few minutes. The same check runs on every sync, so a sync that creates nothing reports the same reason in Sync History. See the Grant the integration user access to Contacts and Leads step in Prepare Salesforce.
The integration user is missing object CRUD or field-level security on the Tightknit objects. Assign the Tightknit Integration User permission set, or, if you use your own, grant the equivalent access from Building your own integration user permission set. The two most common gaps are Modify All Records on the three Tightknit objects and field-level security on Member__c.Contact__c.
This typically means the integration user is on the free, API-only Salesforce Integration license, which we recommend against (see Run the setup wizard). The most reliable fix is to move the user to a UI-capable license such as Salesforce Platform. If you must stay on the Salesforce Integration license, you also have to assign the Salesforce API Integration permission set license (PSL): Setup → Users → [integration user] → Permission Set License Assignments → Edit Assignments. Without it, the license doesn’t grant entitlement to managed-package custom objects, and object describes fail even with the Tightknit Integration User permission set assigned.
The user’s license may be capping access above the permission set. A permission set can only grant what the license permits. A restrictive license (some Platform licenses, or a Salesforce Integration license that doesn’t include Contact) leaves the grant visible in Setup but nullified at runtime. Use a license that includes the object (Contact requires a CRM-capable license), or confirm effective access with the connection test in Tightknit Studio, which checks as the integration user.
During Connect, the OAuth popup closes with a generic “Something went wrong. We couldn’t complete the connection.” message. Tightknit Studio only knows the Salesforce authorization didn’t complete; the specific reason is on the Salesforce side. Check Setup → Login History in Salesforce (filter to the time of your attempt) to see the real error. The two most common causes:
  • OAUTH_APP_ACCESS_DENIED (“user is not admin approved to access this app”). Your org requires admin approval for the Tightknit Salesforce External Client App, and the user completing the connection isn’t authorized for it. Fix it in Setup → External Client App Manager → Tightknit Salesforce → Policies → OAuth Policies → Permitted Users: either set “All users may self-authorize”, or keep “Admin approved users are pre-authorized” and click Manage Permission Sets to add a permission set the connecting user holds (for example Tightknit Integration User or Tightknit Admin). See Configure the External Client App OAuth Policies, then retry the connection in Studio. The related OAUTH_APPROVAL_ERROR_GENERIC error has the same cause and fix.
  • Connecting a sandbox org. Sandbox orgs aren’t supported and fail the OAuth the same way, so connect a production org instead. See Known issues.
  • The integration user can’t log in (Salesforce Integration / API-Only license). If you connect as a user on the Salesforce Integration license or API Only profile, the interactive OAuth login is blocked and Login History shows a login failure. Connect as a UI-login-capable user instead (see the license note in Run the setup wizard).
Resolve the underlying cause first (most often the integration user’s Contact access, see above), then click Retry on the backfill in Tightknit Studio. Re-running is safe: records are matched by ID and updated in place, so it re-attempts the failed records without creating duplicates (though it will overwrite manual edits made to already-synced records).
Members must sync before their Activities. When the member sync fails (commonly the Contact-access issue above), activities that reference those members can’t resolve the lookup and fail too. Fix the member sync first, then re-run the backfill. The activity errors clear once the members exist in Salesforce.
The signed-in user is missing read access to the Tightknit objects. Assign the Tightknit Users permission set group (which grants the packaged Tightknit Read Only access) via Setup → Permission Set Groups → Tightknit Users → Manage Assignments → Add Assignment, then refresh. Without it, the components show an empty state even when the data has synced correctly, because the records are there but the user can’t read them. To grant access org-wide, see Permission set group.
This is an Org-Wide Default sharing setting, not a sync problem. Open Health Check on the Tightknit Setup tab of the Tightknit app and use Fix in Setup on any flagged object to adjust its sharing settings.

​
Reference

​
Known issues

  • Salesforce sandbox orgs are not supported. You can install the managed package in a sandbox and explore the Lightning Web Components (LWCs) by populating Community, Member, and Activity records manually. However, connecting a sandbox org to Tightknit is not supported yet (this is a work-in-progress feature). To run the full integration, connect a production org instead.
  • Salesforce configuration is shown per Studio user, not tenant-wide. The Studio currently scopes the Salesforce integration settings to the Studio user who configured them, instead of sharing them across the tenant. Other Studio admins on the same tenant cannot see or collaborate on the same connection. We’re working on making this configuration tenant-wide.

​
Planned features

  • Pre-built report templates
  • Create Member quick action button on Contact detail page
  • Support for Parent Accounts
  • More sync interval options
  • Custom configuration for linking Tightknit Members to Contacts (beyond email matching)

​
Security

Tightknit does not store your Salesforce username or password. Instead, the integration uses WorkOS Pipes, an enterprise-grade authentication infrastructure, to perform a secure OAuth handshake. This process generates a secure, revocable access token that allows Tightknit to interact with Salesforce on your behalf. This token is encrypted at rest and stored securely by WorkOS, a SOC 2 Type 2 and ISO 27001 compliant vendor. You can revoke Tightknit’s access at any time directly from your Salesforce settings.

Security Overview

Learn more about Tightknit’s security practices and compliance certifications.