Setup
How to install Flourish Core, connect your org to Flourish, and put its components on a page.
Overview
Flourish Core is the package that goes on every org running a Flourish product. It carries the pieces the rest of the suite shares: a support request system for raising work with Flourish, a portal framework that builds branded sites over your data from configuration, a replacement activity timeline for record pages, a record merge that works on any object, segment tagging that keeps Salesforce Campaigns in step, and an admin hub where the org's connection to the Flourish platform is set up.
Setup is five jobs, done once:
- Assign the permission sets.
- Create the configuration record and paste in your token.
- Add a remote site for your own domain.
- Connect the org to Flourish from the Admin Hub.
- Place the components you want on your pages.
Who gets access
Flourish Core ships four permission sets. Assign them in Setup > Permission Sets.
| Permission set | Gives | Assign to |
|---|---|---|
| Flourish Core: User | The Service Requests tab and the ability to raise and work on requests | Anyone who should be able to raise a request with Flourish |
| Flourish Core: Admin | Everything above, plus the Flourish Core Hub tab, the use of Record Merge, and the right to delete any service request | Whoever administers Flourish in your org |
| Flourish Core: Record Merge | The use of Record Merge and nothing else | Someone who merges records but does not administer Flourish |
| Flourish Core: Portal | The use of a portal, and no access to any object or field | The guest user of a site that serves a portal, and anyone who uses a portal without one of the two sets above |
Connecting the org to Flourish happens on the Flourish Core Hub tab, so whoever does that needs the Admin set.
Assigning a permission set is what makes the tabs visible. You do not add them anywhere; they appear for the people you have granted them to and nowhere else. Add them to an app's navigation if you want them more prominent.
The configuration record
Org-wide settings live in a custom metadata type called Flourish Core Setting, in Setup > Custom Metadata Types. Click Manage Records beside it and create a single record whose Record Name is global, in lower case. That name is what Core looks the record up by, so it has to be exactly that.
| Field | Holds |
|---|---|
| FL API Token | The token Flourish issues you during onboarding |
| FL API Org | Your organization's name in Flourish |
| FL API Env | Which environment this org is, for example prod or sandbox |
| Client Id, Client Secret | The consumer key and secret produced by the connection wizard below |
| Org-Wide Email for SR's | The address service request notifications are sent from |
| Timeline Config | The activity timeline configuration, covered in Activity timeline |
Fill in the token, organization and environment now. The rest is filled in as you work through the steps below, or left blank.
The token is the one credential Flourish gives you and the only one you have to paste by hand. Everything Core sends to Flourish authenticates with it.
A remote site for your own domain
Three things in Core call back into your own org: the connection wizard, capturing the actions the timeline composer offers, and adding a new segment option. All of them need your org's own domain listed as a remote site.
In Setup > Remote Site Settings, click New Remote Site. Name it OrgDomain and paste your My Domain URL as the Remote Site URL: the https://yourdomain.my.salesforce.com address, with no path after it. Leave Active checked.
Without it, those calls fail with a message naming the missing site. Nothing else needs it. Displaying a timeline on a record page does not, and neither does selecting a segment that already exists.
Connecting the org to Flourish
For Flourish to read and write records in your org, it needs credentials of its own. The Admin Hub creates them, proves they work, and sends them across without you leaving the page.
Open the Flourish Core Hub tab and click External Client App under Setup in the left panel.
1. Create the app
The panel names the user the new app will run as, which is whoever creates it. Every call Flourish later makes with these credentials runs with that person's permissions and record access, so create the app as a user who will stay active and keep their access. Nothing in Salesforce warns you if that user is later deactivated; the calls simply start failing.
Enter an App Label. The Developer Name fills in from it as you type, and you can edit it: it has to start with a letter and hold only letters, numbers and underscores. Click Create App & Get Credentials.
2. Copy the credentials and test them
The next panel shows Consumer Key (Client ID), Consumer Secret and Instance URL, each with a copy button beside it. The secret has a show and hide toggle; the copy button always copies the real value whichever way it is set.
Salesforce does not always hand the secret back. When it does not, the panel says Last step: copy the Consumer Secret and tells you where to get it: click Open in Setup, open your new app, open its OAuth Settings, then click Consumer Key and Secret to reveal it. Paste it into the Consumer Secret field. This is normal rather than a fault, and the rest of the page works the same way once the secret is in.
Click Test Connection. It requests a real token with the key and secret and tells you what came back, so you know the app works before you go any further.
Then copy the key and secret onto the Flourish Core Setting record as Client Id and Client Secret. The wizard holds them in your browser only while the page is open and never saves them for you.
Those two are also what lets the Segment Picker create a new segment option, so fill them in even if you are not sending anything to Flourish yet. See Segments.
Start Over clears the panel and takes you back to the form. It does not delete the app it created.
3. Give Flourish access
A successful test reveals Give Flourish access to this org. Check the Organization and Environment shown, then click the button. The secret is sent once and cannot be read back afterwards.
If the result says part of the send failed, click the button again. It re-arms as Send Again, and repeating the call finishes the job.
In a sandbox, the environment defaults to sandbox so a run there cannot overwrite what production sent.
Placing the components
Service requests need nothing placed. The Service Requests tab and the service request record page both ship with the package, laid out and assigned, and both open requests in the same place. The Admin Hub is not placed anywhere either: it is the Flourish Core Hub tab.
That leaves the components you place yourself, in the Lightning App Builder or Experience Builder:
| Component | Goes on | Covered in |
|---|---|---|
| Flourish Core: Activity Timeline | Any record page, and Experience Cloud pages | Activity timeline |
| Flourish Core: Record Merge | A record page or an app page | Record merge |
| Flourish Core: Segment Picker | A record page | Segments |
| Flourish Portal | An Experience Cloud page, a Lightning app page or a record page | Portals |
Keep the service request page that ships. It holds the portal that the Service Requests tab uses, which is what makes a request opened from search or a link look and behave the same as one opened from the tab. The older Flourish Core: Service Request Detail component is still in the package but is no longer used.