Skip to content

Prepare your CRM

Written for your Salesforce or HubSpot admin. If you’re the Knowhere manager setting up the connection, forward this page (or use the Copy message for your admin button on the Verify step, which generates the same request pre-filled for your org).

Knowhere writes into your existing companies, contacts, meetings, and notes. It only ever adds its own fields. It never modifies or deletes a field you created, and removing Knowhere later leaves its fields in place, empty, rather than dropping columns your reports may depend on.

How much work this is depends entirely on which CRM you’re on.


Nothing to do in advance. Knowhere creates the properties it needs itself, during the connection.

Connect as a user who can grant app permissions for the portal. Knowhere requests read and write on companies and contacts, read on owners, and read and write on the company and contact property schemas. That last pair is what lets it create its own properties instead of asking you to.

If the Verify step reports a field as Not created, it’s a permission that wasn’t granted. Reconnect, approve the full set, and click Check again.


Salesforce doesn’t allow an app to create schema, so there’s a one-time manual step. Budget about 15 minutes.

1. Check the connecting user’s permissions

Section titled “1. Check the connecting user’s permissions”

The user who authorizes the connection sets the ceiling on everything Knowhere can do. They need:

  • API Enabled on their profile or permission set.
  • Read and write on Account and Contact. Knowhere updates these records in place.
  • Read and write on Event. Knowhere pulls activity history from here and also writes completed meetings back to it.
  • Read and write on ContentNote (Notes) — labeled Content in Salesforce’s own object pickers, not ContentNote. Knowhere writes debrief notes here; it never reads existing notes.
  • Read only on Task and Opportunity. Knowhere pulls call activity and deal data from these but never writes to either.

Connecting as a restricted user doesn’t fail loudly. It quietly limits what can sync.

2. Turn on Notes for your org, if it isn’t already

Section titled “2. Turn on Notes for your org, if it isn’t already”

Debrief notes sync to Salesforce’s ContentNote object — if you go looking for it in Object Manager or a permission set’s object list, it’s shown as Content, not ContentNote. If your org has never enabled Notes, that object doesn’t exist in your schema at all, and Knowhere has nothing to describe or write to. It won’t show as a clear error, just an object that never becomes ready.

Check Setup → Notes Settings and turn on Enable Notes if it’s off. Most orgs already have this on; it only matters if debrief notes aren’t showing up on Knowhere’s Notes mapping tab later and everything else checks out.

This is the field Knowhere uses to recognize a record it already synced, so it updates that record instead of creating a second copy. It holds none of your data. Nothing syncs to Salesforce without it.

Create the same field on two objects:

  • Account
  • Contact

Not on Event or ContentNote. Salesforce’s Event object can’t carry an External ID field at all. ContentNote is file-backed and accepts no custom fields either. Knowhere correlates both a different way. If you’ve seen an older instruction naming three or four objects, two is correct.

For each one:

  1. Go to Setup → Object Manager and open the object.
  2. Click Fields & Relationships → New.
  3. Choose Text. Click Next.
  4. Field Label: type Knowhere External Id, with the spaces, exactly as shown. Don’t type the API name yourself. Salesforce derives Knowhere_External_Id__c from the label automatically; typing an underscored, __c-suffixed string into the Label box instead makes Salesforce double the suffix (you’ll end up with something like Knowhere_External_Id_c__c), which Verify will only ever report as a plain “missing” field with no hint why.
  5. Length can stay at the default.
  6. Check Unique. Check External ID. Both are required. A field missing either one will not work.
  7. Set field-level security so the connecting user can read and write it, and save.

The Knowhere manager can then click Check again on the Verify step and should see Ready against both.

Section titled “4. Create the reporting fields (recommended)”

These nine fields are where event history lands as structured values rather than prose, so a post-meeting summary becomes something you can build a list view, report, or workflow on.

Same place for each: Object Manager → the object → Fields & Relationships → New. Field types matter. A date created as Text can’t go in a date filter and a count created as Text can’t be summed, which defeats the entire purpose. The Field Label column is what your users will see; the Field Name column is what Knowhere writes to, so it has to match exactly.

On Account (6 fields):

Field NameField LabelTypeHolds
knowhere_last_eventKnowhere Last EventTextMost recent event this organization was met at
knowhere_last_event_dateKnowhere Last Event DateDateDate of that event
knowhere_meeting_countKnowhere Meeting CountNumberMeetings held with this organization
knowhere_last_debrief_dateKnowhere Last Debrief DateDateWhen the most recent debrief was filed
knowhere_open_followupsKnowhere Open Follow-upsNumberFollow-ups still open from any debrief
knowhere_debrief_outcomeKnowhere Debrief OutcomeTextOutcome flagged on the latest debrief

On Contact (3 fields):

Field NameField LabelTypeHolds
knowhere_last_met_dateKnowhere Last Met DateDateWhen this person was last met
knowhere_meeting_countKnowhere Meeting CountNumberMeetings this person attended
knowhere_last_eventKnowhere Last EventTextMost recent event this person was met at

Two things to know before you spend the time:

  • There’s no verification step for these. The Verify screen checks the identity field only. Nothing will tell you a reporting field is missing or misspelled; the value just never arrives.
  • They start empty and stay empty for now. Knowhere creates the fields (or asks you to) so the schema is ready, but filling them in automatically after each debrief isn’t live yet. If you’d rather wait and add them when they do something, that’s a reasonable call. Adding them now just means nobody has to come back to this screen later.

Testing against an empty org tells you very little. A handful of Accounts, Contacts spread across them, a couple of open and closed Opportunities, and a few Events is enough to see the whole loop work.


For transparency, and for the security review that usually accompanies a request like this:

  • Reads companies, contacts, and open opportunities, limited to the scope the Knowhere manager chose (a list, a filter, a pasted set of accounts, or everything updated in the last 24 months).
  • Reads the owner roster, to match CRM account owners to Knowhere team members by email address.
  • Reads meeting and call activity onto a read-only mirror. It never creates a meeting in Knowhere from this.
  • Writes completed meetings and filed debriefs, plus its own fields listed above.
  • Never writes to your deals or opportunities. Pipeline, stage, and value are read-only in every direction, including the Pipeline widgets on the event page, which only ever read.
  • Never deletes your records.

Free-text fields (notes and descriptions) are held back from outbound writes by default.

Credentials are encrypted at rest. Disconnecting from Settings → CRM Sync clears them and drops anything still queued to send.