UserEvidence Advocacy — Salesforce Admin Setup Guide

No developer experience is required. If you can install a managed package, assign a permission set, and edit a Lightning page, you can complete this setup. Budget about 45–60 minutes end-to-end.

Two guides, two audiences. This is the admin setup guide. For a plain-language explanation of what the tool does and how sellers and program managers use it day to day, see the companion Features & Team Guide.

About the "Zealot" name. You'll spot zealot / joinzealot.com in a few field API names and URLs (e.g. the API host api2.joinzealot.com). That's the product's original name — UE Advocacy was previously Zealot. The functionality is identical, and those API names can't be renamed because the sync depends on the exact strings. Nothing for you to do; just don't be surprised by them.

UE Advocacy connects your Salesforce org to the UserEvidence advocacy platform so reference and advocacy activity is visible, actionable, and reportable right inside Salesforce. Three things move between the two systems:

The package supports two advocate journeys:

Installing (or upgrading) the package adds the following to your org. Every custom API name carries the UserEvidence__ namespace prefix in your org.

Setup → Permission Sets, then for each set: Manage Assignments → Add Assignments → select users → Assign.

The Integration set exists specifically for the connection's Run-As user. Assign it in Step 7 — not to your everyday users.

The UE Advocacy record page ships preconfigured — those records open with the stage bar and grouped fields, no action needed.

The package can't place fields on your standard Opportunity layout, so add them once so the writeback is visible:

Using Dynamic Forms / an Opportunity record page (Flexipage)? Add the same fields there instead: Setup → Object Manager → Opportunity → Lightning Record Pages → edit the page → drag the fields onto the form → Save & Activate.

The UE Advocacy Configuration tab (visible to UE Advocacy Admin) stores your org's UserEvidence token and settings.

Base URL stays locked to the UserEvidence production endpoint (api2.joinzealot.com) — no action needed. Proactive matches is an optional toggle, off by default.

On the same Configuration screen, the Field Selection tab is where you pick which Salesforce fields UserEvidence should sync, per model and direction.

The package only stores your picks; UserEvidence reads them and owns the mapping on its side. You're just telling it which fields you want in play.

This is how UserEvidence securely writes reference activity and advocate contacts back into your org. It uses a packaged External Client App (ECA) — you never handle any keys or secrets; you just enable the flow and nominate a user. ~20 minutes, once per org (and once per sandbox you want connected).

What "Run As" means: UserEvidence acts as a Salesforce user you nominate. Whatever that user can see and edit is exactly what UserEvidence can — nothing more.

7a — Create the Run-As user

This free, API-only license is Salesforce's purpose-built integration user — nobody can log in as it through the UI (that's intended). An existing active, API-enabled user also works for a quick sandbox test, but a dedicated user is strongly recommended for production.

7b — Give that user access

Use UE Advocacy Integration for the Run-As user (not Admin, not User). It's the least-privilege set built for exactly this.

7c — Enable the connection

7d — Send UserEvidence your domain

Send your My Domain URL to UserEvidence (find it under Setup → My Domain), e.g. https://yourcompany.my.salesforce.com. For a sandbox, send that sandbox's domain (it differs from production). UserEvidence confirms the connection from their side.

That's the whole connection. No keys, no secrets, nothing to copy out of Salesforce.

UserEvidence pulls your advocate contacts into its platform, and it decides which contacts to pull from a packaged field on Contact — UE Advocate Status. So there are two parts: surface the fields, then decide how contacts get flagged.

8a — Add the Contact fields to your layout

The package adds two fields to Contact but can't place them for you, so add them once:

Using Dynamic Forms / a Contact record page (Flexipage) instead of a classic layout? Add the same two fields there: Setup → Object Manager → Contact → Lightning Record Pages → edit the page → drag the two fields onto the form (or into a Field Section) → Save & Activate.

Field-level security: the packaged permission sets already grant access to these fields, so assigned users can see/edit them once they're on the layout. If a user can't see a field, confirm their permission-set assignment (Step 2).

8b — Flag the contacts to sync

Once a contact is Should Be Advocate, UserEvidence picks it up on its next sync and marks it Is Advocate automatically.

Skip this unless you use the referral flow (advocates submitting leads). A few fields live in your org, not the package:

You do not need to add any Remote Site Settings or Trusted URLs by hand — the package ships them:

The reference request form itself runs server-side (through Apex, using your stored token), so there's no browser API call for it to allowlist.

Run through this checklist after setup:

Installing the package carries the components (objects, fields, Apex, components, reports), but not your per-org configuration. So after installing in production, redo the config there:

A change set / metadata deploy can carry the layout, Lightning page, field, and Field Selection config from sandbox to prod. Permission-set assignments, the API token, and the ECA connection must still be done directly in production. Test data does not migrate.

References move through a fixed, linear set of stages. Match these strings exactly in reports and automation:

Requested → Awaiting Advocate → Awaiting Prospect → Booked → Completed, plus Cancelled (terminal). Don't rely on any other status values.

On the Opportunity (written back by the package):

On Contact (for the advocate sync): UE Advocate Status (UE_Advocate_Status__c) and UE FanUser UUID (UE_FanUser_Uuid__c).

Never rename an existing field API name. The sync depends on the exact strings and will break if they change.