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 by email matching. You can manually override any incorrect links.
  • 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 a configurable lookup that links each member to a standard Salesforce Contact:
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:
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=04tdM000000Xu6fQAC

​
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 strongly 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.
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 Read access to Contacts

The Tightknit sync matches your community members to your existing Salesforce Contacts by email, so the integration user needs permission to read Contacts. The Tightknit Integration User permission set does not include this, 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 the Contact object (and Create too, but only if you turn on Create Contacts later). Pick whichever way fits how your org is set up:
  1. Add a minimal extra permission set (recommended). Create a new permission set, give it Read on Contact, 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 turn on Read for the Contact object 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 Workspace > Users 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 — create a new Salesforce Contact for any community member that cannot be matched by email.
  • Activity Metadata — include additional metadata fields on synced Activity records.
  • Matching field — the Contact field used to match community members (default: email).
  • 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

​
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.
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.

​
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 sample page layouts and custom Lightning Web Components that you can add to your Salesforce pages using Lightning App Builder. 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 — 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 enable the Create Contacts option in Start the sync. Without that setting on, Read alone is sufficient.
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 field to miss: Member__c.Contact__c. This is a lookup field pointing at the standard Contact object, and admins commonly skip over it when granting field-level security, partly because lookups feel like they should be governed by the target object’s access alone. They aren’t: the lookup field on Member__c needs its own FLS grant. Missing it produces a Field name not found Bulk V2 error that looks like a missing field rather than a permissions gap.

​
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.
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 Give the integration user Read access to Contacts. Add Create as well if you enable Create Contacts.
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 Leads
  • 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.

Related topics

StudioActivity LogsActivity Log Metadata VersionsAccess the Studio