Skip to main content

Setup

How to get Flourish Arbor ready in an org after installing it: permissions, the session cache, the address Arbor sends email from, and the Experience site your members sign in on.

Overview​

Arbor lets people sign in to resources you keep in Salesforce without making them Salesforce users. A member signs in on an Experience site page, with a password, an emailed code, a magic link or an authenticator app, and Arbor keeps their session itself. No license is used, so a network can hold thousands of members.

Arbor also records who those people are and how they relate. Every member is an Arbor Element in an Arbor Network, tied to the Contact or other record they represent, and elements can be linked to one another. Networks and Members cover that model.

Setup is done once per org:

  1. Assign the permission set.
  2. Give Arbor's session cache some space.
  3. Set the address Arbor sends email from.
  4. Open an Experience site to members.

Permission sets​

Permission setGive it to
Flourish Arbor: Super AdminPeople who manage networks and members. Grants the Arbor Networks tab, both Arbor objects, the Provision Member tool and the Member Access panel.
Flourish Arbor: Product ServerOnly the run-as user of a connected app that a Flourish product uses to sign members in from outside Salesforce. See Flourish products outside Salesforce. Never give it to a site guest user.

The Super Admin set leaves out every credential field: password hashes, authenticator secrets and link tokens. Nobody needs to read them, and Arbor keeps them hashed or encrypted in any case.

Members get no permission set. They are not Salesforce users.

Platform Cache​

Arbor keeps sessions in Platform Cache, in a partition the package installs called AuthSessions. It installs with no space allocated, and until it has some, nobody stays signed in.

  1. In Setup, open Platform Cache.
  2. Edit the AuthSessions partition.
  3. Give it at least 2 MB of Organization cache, and save.

The org has to have Platform Cache capacity to give. If there is none left to allocate, add capacity before members try to sign in.

Sender address​

Some Arbor emails go out because a member did something on the site: asked for a sign-in link, a code, or a password reset. Salesforce sends those as the site's guest user, and most mail servers reject or spam-file mail from that sender. The page tells the member the email is on its way, and it never arrives. Emails an admin triggers from Salesforce are not affected, which makes the problem easy to miss in testing.

The fix is one verified address that all Arbor email goes out from:

  1. In Setup, open Organization-Wide Addresses and add the address, for example members@yourorg.org. Verify it from the email Salesforce sends.
  2. On that address, select Allow All Profiles to Use this From Address. The site's guest user needs it.
  3. In Setup, open Custom Metadata Types and click Manage Records next to Flourish Arbor Settings.
  4. Edit the Default record, put the address in Sender Email, and save.

From then on every Arbor email comes from that address, under that address's display name. A network's own Email From Name is used only when Sender Email is blank.

Experience site​

Members sign in on an Experience Cloud site, either one you already run or a new one. Sign-in Pages covers which components go on which pages.

Every Arbor page is public as far as Salesforce is concerned. Members are not Salesforce users, so they reach the site as its guest user whether they have signed in to Arbor or not. The Auth Guard component is what keeps a page to members. So:

  1. In Experience Builder, open Settings and allow guest users to see the site without logging in.
  2. Set the page access of every page that carries an Arbor component to Public.
  3. Open the site's guest user profile (it is linked from Settings in Experience Builder) and, under Apex Class Access, add arbor_AuthPublicUtility. It is the only Arbor class a guest needs. Grant no object or field permissions for Arbor: it reads and writes its own records itself.
  4. Publish the site.

Grant the guest user nothing else from Arbor, and never the Product Server permission set.

Flourish products outside Salesforce​

Some Flourish products run outside Salesforce and sign their users in with Arbor. The member clicks a magic link, the product asks your org whose link it is, and the product signs them in itself. The product calls in to Salesforce; nothing in Arbor calls out.

Set this up only when a Flourish product needs it:

  1. Create a connected app with the OAuth client credentials flow enabled, and choose a Run As user for it. A dedicated integration user is the safest choice.
  2. Assign Flourish Arbor: Product Server to that user. It grants the one sign-in service the product calls and nothing else.
  3. Give Flourish the org's My Domain URL and the connected app's consumer key and secret.
  4. On each network the product uses, set Auth Site URL to the product's sign-in page, which Flourish provides, rather than to a page on your site.

Second factors don't carry over. The product has no step for one, so Arbor refuses a member's sign-in when the network's MFA Policy is Required, or when the member has a second factor of their own, rather than let them skip it.

Checking it works​

  • Open Arbor Networks from the App Launcher. If it is missing, the permission set is not assigned, or was assigned in this session: log out and back in.
  • Create a test network as described in Networks, with Magic Link allowed and an Auth Site URL. Provision yourself with Delivery set to None - return the link to me, and open the link. The protected page should load.
  • Reload that page. If it sends you to the sign-in page, the AuthSessions partition has no space.
  • On the site's sign-in page, enter your own username. If the page says a link is on its way and nothing arrives, Sender Email is blank, or the address does not allow all profiles.
  • If every sign-in on a network fails, check its Allowed Auth Methods and Status first.