Audience: Salesforce administrators setting up the UE Advocacy managed package after it has been installed.

This guide covers everything needed to stand up UE Advocacy in your org: granting access, placing the Lightning components, connecting your UserEvidence account, and wiring up the UserEvidence → Salesforce connection. No developer experience is required. If you can install a managed package, assign a permission set, and edit a Lightning page, you can finish this setup. Budget 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 Managed Package User Guide.

💡 About the "Zealot" name. You may see zealot / joinzealot.com in a few field API names and endpoint URLs (for example the API host api2.joinzealot.com). That is the product's original name — UE Advocacy was previously called Zealot. The functionality is identical, and those API names cannot 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 inside Salesforce. Three things move between the two systems:

The package supports two advocate journeys:

Before you begin, confirm the following:

Install into a sandbox first, complete the configuration below, verify it, then repeat the same steps in production.

Complete these steps in order. The permission-set detail is expanded in Section 5.

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 4.6, 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 cannot place fields on your standard Opportunity layout, so add them once to make the writeback visible:

💡 Using Dynamic Forms or 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. It is backed by a protected custom setting, so the token is never displayed back once saved.

Two parts: mint the token in UserEvidence, then paste it into Salesforce.

4.4a Mint the token (in UserEvidence)

⚠️ The scope must include write. When a seller submits a request, the panel writes to UserEvidence using this token. A read-only token still saves, still shows "API token is configured", and still lets the panel load contacts — it fails only when a rep tries to submit.

💡 Tokens don't expire. They stay valid until someone revokes them in Token Management. Revoking the token the package is using breaks the panel and the advocate sync.

💡 Can't see Token Management? Your UserEvidence CSM can mint the token for you.

4.4b Save the token (in Salesforce)

Pasting a new value later simply rotates it.

💡 Sandbox and production each need their own token. Mint one per org in 4.4a and name them so you can tell them apart. The sandbox token does not carry over.

💡 Base URL stays locked to the UserEvidence production endpoint

(api2.joinzealot.com) — no action needed. Proactive matches is an optional toggle, off by default.

Reference actions. The same screen has a Reference actions dropdown controlling which buttons the Reference Management panel offers reps:

⚠️ If self-serve references are turned off for your brand in UserEvidence, set this to "Request only." The panel cannot see that setting on its own yet, so leaving it on Automatic will still show Choose — and requests raised that way carry only the basic fields, not your configured form questions. This setting applies to both the Opportunity panel and the Reference Management action button.

On the same Configuration console, 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 are 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 enable the flow and nominate a user. Allow about 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.

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

💡 Use UE Advocacy Integration for the Run-As user, not Admin and not User. It is the least-privilege set built for exactly this.
​

Paste your My Domain URL into your UserEvidence Integrations settings (find your My Domain URL under Setup → My Domain), for example 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 is 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. There are two parts — surface the fields, then decide how contacts get flagged.

💡 Using Dynamic Forms or a Contact record page (Flexipage)? Add the same two fields there: Setup → Object Manager → Contact → Lightning Record Pages → edit the page → drag the two fields onto the form → Save & Activate.

You have two ways to do this. Pick one.

Option A — use the UE Advocate Status field (the default).

Option B — point us at your own field (Advocates tab).

Use this if you already track advocates on Contact, or you want the rule to live in Salesforce rather than in a Flow:

💡 Rules more complex than a checkbox? Create a single formula field on Contact of type Checkbox that returns true when someone should be an advocate, then select it here. A formula can look at the parent Account, record types, multi-select picklists and so on, so an entire eligibility rule fits in one field. Formulas are also always up to date, so a newly qualifying contact is picked up with no extra work.
​
​One tradeoff: formula fields are not indexed. If you have a very large number of contacts, a plain checkbox kept up to date by a Flow will sync noticeably faster than a formula.

Selecting nothing on the Advocates tab keeps Option A. Choosing fields here replaces the UE Advocate Status rule — contacts are then selected purely by your criteria.

⚠️ If a contact later stops matching your criteria, they are not removed from UserEvidence. They keep their UE FanUser UUID and stay as an advocate there. Take them out of scope in UserEvidence directly.

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

Earlier versions of the package shipped without permission sets, and you may see older notes to that effect. The current package ships three permission sets. Grant access with these rather than editing profiles by hand:

Note on Opportunity access: the packaged sets grant the package's own objects and fields, but standard object access has to come from your org — Salesforce does not let a managed package grant permissions on standard objects such as Opportunity.
​
Your everyday users get theirs from their profile as usual. The Run-As user needs it explicitly, because an API-only user starts with no standard object access at all: give it Read + View All Records on Opportunity, with no Edit, as described in Step 4.6b.

Run through this smoke test after setup:

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

💡 A change set or 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). Do not 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.