Salesforce is Uni Compare's native-supported CRM. The integration uses a Connected App you create in your Salesforce org. Leads are written as Contact records, deduplicated by email.

Salesforce is fully supported by Uni Compare, and uses a Connected App OAuth credential created within your Salesforce org.

What we need from you

The Consumer Key (Client ID) and Consumer Secret of a Connected App in your Salesforce org, configured with OAuth scopes api and refresh_token.
Your environment: production or sandbox (this determines the Salesforce login URL we use: login.salesforce.com or test.salesforce.com).
If you have a Salesforce sandbox, create a separate Connected App in the sandbox org and send us its Consumer Key and Consumer Secret too. We use the sandbox for the pre-go-live test.

Note: an authorised Salesforce admin from your team will need to complete a brief one-time OAuth login when we set up the integration (we'll coordinate a short session, typically five minutes). Your admin's password is never transmitted to us; they enter it directly into Salesforce's login page in the browser.

Where in Salesforce to set it up

Step 1. Create the Connected App

Setup → Platform Tools → Apps → External Client Apps → Settings. Scroll down to the "Connected Apps" section at the bottom of the page and click "New Connected App". Name the app "Uni Compare lead delivery". In the "API (Enable OAuth Settings)" section:

Tick Enable OAuth Settings.
Set the Callback URL to https://n8n.universitycompare.com/rest/oauth2-credential/callback.
Under Selected OAuth Scopes, add exactly these two scopes and leave everything else unselected:
- Manage user data via APIs (api): lets the integration create and update Contacts via REST.
- Perform requests at any time (refresh_token, offline_access): lets the integration obtain a refresh token and maintain a working session.
Do not select Full access (full). See the FAQ below.
Leave all other OAuth checkboxes (PKCE, Require Secret for Web Server Flow, Enable Client Credentials Flow, Token Exchange Flow, JWT-based tokens, Enforce Refresh Token IP Allowlist, etc.) unchecked.

Save the app.

Step 2. Wait for Salesforce propagation

Salesforce recommends waiting up to ten minutes after creation before using a new Connected App for the first time. Salesforce is still propagating the app's configuration. If you try to authorise before that finishes, you may see an invalid_client_id or "app not found" error. This is normal and clears once propagation completes (typically 5–30 minutes).

Step 3. Set the OAuth policies

Setup → App Manager → find your app → click the row dropdown → Manage and press the Edit Policies button

IP Relaxation: "Relax IP restrictions". Our middleware does not use a fixed source IP. If your security team requires IP restrictions enforced, contact us via the support chat and we'll provide our egress IP for your allowlist.
Refresh Token Policy: leave as "Refresh token is valid until revoked" (the default).
Permitted Users: leave as "All users may self-authorize" (the default). For stricter security with admin pre-authorisation, see the FAQ.

Step 4. Copy the Consumer Key and Consumer Secret

Setup → App Manager → find your app → row dropdown → View. Scroll down to "API (Enable OAuth Settings)". Next to "Consumer Key and Secret", click "Manage Consumer Details". Salesforce emails you a verification code. Enter it. A separate page shows the Consumer Key and Consumer Secret. Copy both immediately. After you send the credentials, we'll schedule a brief OAuth login session with your Salesforce admin to complete the connection. The app will then appear in Setup → Connected Apps OAuth Usage automatically after the first successful OAuth authorisation.

Verify before sending

Before sending the credentials, confirm the following:

Both items captured. You have the Consumer Key and Consumer Secret you copied in Step 4.
Environment identified. You know whether these credentials are for your production org or your sandbox org. If you have both, you have two separate Connected Apps with two separate Consumer Key / Secret pairs.
OAuth scopes correct. On the Connected App's API section, Selected OAuth Scopes shows those two scopes and nothing else. Not Full access.
OAuth policies set. The propagation delay has passed, and Edit Policies shows: IP Relaxation = "Relax IP restrictions", Refresh Token Policy = "Refresh token is valid until revoked".
Channel. Generate a one-time encrypted link using our secrets page with Consumer Key + Consumer Secret + environment label, then email the link to your Uni Compare contact.

Important: Never paste credentials into a web chat, plain email, or any unencrypted attachment.

Field mapping

We create Contact records in Salesforce (not Lead), deduplicated by email. If a contact with the same email already exists, we update it; otherwise we create a new one.

We pass each lead to you with the following fields, mapped onto Salesforce's standard Contact fields where possible and at times onto custom fields otherwise (must be agreed with you at onboarding for the exact custom-field API names).

If your org already has fields for some of these, please share these with the Uni Compare team so we can map onto those:

First name and last name → standard FirstName, LastName
Email → standard Email
Phone (where given) → standard Phone
Postcode → custom field
Address (where given) → custom field
Study Level (undergraduate or postgraduate) → custom field
Start Year → custom field
Subject Area (where given) → custom field
Free-text enquiry message (where given) → custom field
Lead type → custom field
Marketing consent flag → custom boolean field (you choose how to use it in your marketing automation)
Uni Compare lead identifier → custom field (for traceability)

Frequently asked questions

How does the one-time OAuth login work?

When we begin integration setup, an authorised Salesforce admin from your team logs into Salesforce via our integration UI in a short coordinated session (typically five minutes, screen-share or follow-along is fine). Salesforce shows your admin a consent screen asking them to grant the Connected App access to your org. After they confirm, Salesforce returns a refresh token to our system, which we then use to obtain access tokens automatically for the lifetime of the integration. Your admin's password is never transmitted to us. They enter it directly into Salesforce's standard login page, which Salesforce serves in their browser. We only ever see the refresh token Salesforce gives us, which is scoped to the two OAuth scopes you configured.

Why not use "Full access (full)" scope?

Full access (full) lets the app do anything the authenticated user can do, well beyond Contacts. The integration only needs to create and update Contact records, so that's all we ask for. If the Consumer Key/Secret or refresh token ever leaked, a narrow scope keeps the damage to contacts instead of your whole org. The two scopes we use (api + refresh_token) are the minimum needed to create and update contacts and keep the token refreshed.

Should we use "Admin approved users are pre-authorised" Permitted Users for tighter security?

You can, but it adds a configuration step. With "Admin approved users are pre-authorised", only users in profiles or permission sets that have been explicitly pre-authorised for the Connected App can complete the OAuth login. To use this path: (1) On Edit Policies, set Permitted Users to "Admin approved users are pre-authorised". (2) Go to Setup → App Manager → find your app → Manage → "Manage Permission Sets" and add the permission set or profile of the admin who will do the OAuth login. Without that pre-authorisation step the OAuth login will fail.

"Manage Consumer Details" is asking me for a verification code. Is that normal?

Yes. Since 2024 Salesforce protects Consumer Secret retrieval with an extra identity check. When you click "Manage Consumer Details", Salesforce emails a verification code to the address on your user record. Enter the code on the page that appears, and Salesforce will then display the Consumer Key and Consumer Secret. If you do not receive the code, check spam, and confirm your user's email is correct on the User Detail page.

Why is "New Connected App" now under External Client Apps?

Salesforce introduced External Client Apps in 2024 to eventually replace Connected Apps, and in 2025–2026 they reorganised Setup so that Connected App creation lives under Setup → Platform Tools → Apps → External Client Apps → Settings, with the "New Connected App" button at the bottom of that page. If you find older Salesforce tutorials online that point you to Setup → App Manager → New Connected App, those are outdated. Despite the new location, the Connected App you create is functionally identical to one created the old way.

Should we use an External Client App instead of a Connected App?

Not yet. External Client Apps are where Salesforce is heading, but as of mid-2026 most third-party integrations still use the Connected App OAuth flow. We'll move this guide and our integration over when that changes. For now, Connected App is the right choice.

Can you create Lead records instead of Contact records?

By default, we create Contact records, which works for most universities. If your org strictly uses Lead for un-qualified prospects and you need leads delivered there, tell us at onboarding. It's a small change on our side.

Useful links

Create a Connected App — Salesforce's reference for the full Connected App setup flow with all OAuth settings explained.
OAuth tokens and scopes reference — the full list of Salesforce OAuth scopes, useful if your security team wants to verify the scopes we ask for are minimal.

Salesforce Integration