Connect Fonteva

Fonteva lives inside your own Salesforce org, so Sessionboard CRM reads it through Salesforce. Your Salesforce admin creates an app that Sessionboard signs in with, and a user that app runs as, with read access to the Fonteva objects. Sessionboard then reads your members, their member type, status, join and renewal dates, and the event registrations Fonteva keeps.

Why use it

Your members are in Fonteva and your speakers, reviewers and attendees are in Sessionboard. Connecting the two shows which members take part and which never do, without anyone exporting a spreadsheet, and keeps the Member tag right as people join and lapse.

What Sessionboard reads

Fonteva object	What it’s used for
`OrderApi__Subscription__c`	One membership term per row: status, member type, join and paid-through dates
`OrderApi__Item__c`	The member type’s name
`Contact`, `Account`	The member’s name, email, title and company
`EventApi__Attendee__c`, `EventApi__Event__c`	The event registrations and check-ins Fonteva keeps

Every read is a query. Sessionboard never edits a member, contact, account or subscription. Writing Sessionboard’s own engagement records back is a separate choice, off until you turn it on: see Write engagement back to your AMS.

Set it up in Salesforce

Note your My Domain URL

In Salesforce Setup, open My Domain and copy your org’s URL, such as https://yourassociation.my.salesforce.com. The client credentials flow works only against My Domain, not login.salesforce.com.

Create the run-as user

Create a user for Sessionboard alone, with a mailbox you control. Salesforce recommends the Salesforce Integration user licence with the Minimum Access - API Only Integrations profile, plus the Salesforce API Integration permission set licence. If your org assigns Fonteva package licences per user (Setup > Installed Packages > Manage Licenses), assign one to this user so it can read the Fonteva objects.

Give it read access

Create a permission set, such as “Sessionboard Integration”, with API Enabled and Read on every object in the table above, including read access to their fields. Assign it to the run-as user. Sessionboard reads only what this user can see.

Create the External Client App

In Setup, open External Client App Manager and choose New External Client App. Name it “Sessionboard” and leave the distribution state at Local. Enable OAuth, enter https://login.salesforce.com/services/oauth2/success as the callback URL (the flow requires one but doesn’t use it), add the scope Manage user data via APIs (api) and check Enable Client Credentials Flow.

Set who it runs as

Open the app’s Policies, edit OAuth Policies and, under Client Credentials Flow, set Run As to the user you created. Save.

Copy the key and secret

Open the app’s Settings and, under OAuth Settings, view the Consumer Key and Secret. Salesforce asks for a verification code first.

If you recreate the app later, enable the client credentials flow and set Run As again: a new app starts without them.

Connect it in Sessionboard CRM

Our team connects it with you on Connections using three values: the My Domain URL, the Consumer Key and the Consumer Secret. They’re stored encrypted and never shown again, so don’t send the secret by email. Testing the connection checks that Sessionboard can sign in and read.

Then confirm which fields hold each part of a membership: see Map your AMS fields.

Fonteva and your Salesforce connection

Fonteva uses your organization’s Salesforce connection. If Salesforce is already connected to Sessionboard, Fonteva reads through it, so add the Fonteva read access to that connection’s run-as user. Disconnecting Fonteva disconnects Salesforce too, and the other way round. People you already brought in stay in Sessionboard CRM.