Installation & Configuration

part 2 — initial setup complete these steps in order the whole process typically takes 30–60 minutes, plus background time for the bulk match to finish choose your install audience 🔴 critical before you click install, decide how you want to control user access to the altrata app salesforce will ask you to pick one of three install options, and your choice has long term consequences install for all users — every user in your salesforce org gets access to altrata automatically install for admins only (recommended for controlled rollouts) — only salesforce admins get access at install time you then assign altrata's built in permission sets to grant access to specific users install for specific profiles — access is granted to the salesforce profiles you select 🛑 permission sets in salesforce are additive only once you grant a user access through a permission set, you cannot use permission sets to take it away — you can only stop assigning new ones this means the decision you make at install time is hard to reverse if you install for all users and later decide you wanted granular control, you'll have a much harder cleanup job which option should you choose? if you want to choose roll altrata out to everyone in salesforce immediately, with no per user gating install for all users control which users get access to which altrata features (admin vs match manager vs end user) using altrata's built in permission sets install for admins only limit access to specific salesforce profiles (e g , only the "sales" or "development" profile) install for specific profiles 🟢 recommended if you're not 100% sure which path you need, choose install for admins only you can always grant access to more users later by assigning permission sets — but going the other direction (revoking access after a broad install) is much harder if you chose all users , you can skip ahead to step 1, then jump straight to step 2 (authenticate) permission set planning doesn't apply to you if you chose admins only or specific profiles , complete step 1 (install) and then come back to step 1a — configure permission sets before continuing step 1 — install the package 🟡 required click the installation link provided by altrata you'll be prompted to log in to salesforce confirm you're logging in to the correct environment (production vs sandbox) salesforce usernames are unique per environment, so double check before proceeding on the install page, select install for all users , then click install when prompted, approve third party access by checking yes, grant access to these third party web sites , then click continue wait for the install to complete it usually takes 5–10 minutes, but can take longer if you see this message, the install will continue in the background and the salesforce admin will receive an email when it's done step 1a configure permission sets ℹ️ skip this section if you installed for all users salesforce automatically grants access to every user in that case, and no further permission configuration is needed if you chose install for admins only or install for specific profiles , you'll need to manually grant access to the users who should be able to use the app the altrata managed package ships with five permission sets — combine them to give each user exactly the access they need 🟢 recommended plan permissions on paper before assigning them in salesforce identify who will administer the app, who will manage matches, and who will simply use altrata data on records the altrata permission sets permission set what it grants altrata credential management permissions required to set up altrata api credentials on the altrata authentication tab needed once during initial setup altrata app configuration permissions required to administer the app post installation limited to data controls and configuration tabs altrata background job execution permissions required to execute background tasks such as bulk matching altrata match management permissions required to manage, accept, or reject possible match results altrata standard capabilities permissions required to interact with the non administrative (end user) functions of the app additional salesforce permissions most user roles also need standard salesforce permissions on the objects they'll work with customize application (system permission, for admins) read access to lead, contact, and account write access to lead, contact, and account create access to lead, contact, and account assignment models pick the model that fits your organization each row shows what to assign to a user of that type model a — minimum user types (simplest) use this when you don't need fine grained separation between admin functions user type altrata permission sets additional salesforce permissions app admin credential management, app configuration, background job execution, match management customize application; read / write / create on lead, contact, account standard standard capabilities read / write / create on lead, contact, account model b — match management as a separate role use this when match decisions should be owned by a dedicated person (e g , a data steward) rather than the app admin user type altrata permission sets additional salesforce permissions app admin credential management, app configuration, background job execution customize application; read / write / create on lead, contact, account match manager match management read / write on lead, contact, account standard standard capabilities read / write / create on lead, contact, account model c — security conscious (highest separation of duties) use this when credential management must be isolated from app administration — typically because it/security owns credentials and a separate business admin owns the app user type altrata permission sets additional salesforce permissions it support credential management (none additional) app admin app configuration, background job execution customize application; read / write / create on lead, contact, account match manager match management read / write on lead, contact, account standard standard capabilities read / write / create on lead, contact, account how to assign permission sets in salesforce, go to setup → users → permission sets find the relevant altrata permission set (e g , credential management ) click manage assignments → add assignments select the users who should receive this permission set and click assign repeat for each permission set / user combination from the model you chose above best practices assign credential management sparingly this permission set lets a user enter or change altrata api credentials, which controls the integration's data access limit it to the smallest possible group — ideally one or two trusted admins don't give standard users admin permission sets end users only need standard capabilities plus salesforce object permissions bundling admin sets in for convenience creates audit and security risk document your choice record which model you chose and which users hold each permission set this makes future audits, role changes, and offboarding much easier step 2 — authenticate the integration 🟡 required you won't be able to view or sync altrata data until the package is authenticated with your altrata service credentials in salesforce, click the app launcher (the 9 dot icon in the top left) in the search box, type altrata setting and click the result if you cannot locate altrata settings within the app launcher, ensure the application has been installed correctly and that you have the permissions to access open the altrata authentication tab enter your service account username, password and api key the api key should be received via a separate email click verify if verification fails, double check that yo've entered each value exactly as provided if the error persists, contact support\@altrata com mailto\ support\@altrata com step 3 — configure field mapping 🔴 critical match settings is where you tell the integration which salesforce fields to use for matching (field mapping) and which salesforce records are eligible for matching (data filters) getting both right before you run bulk matching is the difference between a smooth rollout and a frustrating cleanup project why this step is critical field mapping tells the matching algorithm which salesforce fields to read from when finding the best altrata profile for each record the richer your mapping, the better the match rate and match quality — map as many fields as possible matching requires at least one of these four methods to be fully configured first name + last name + organization name — all three mapped together email — at least one email field mapped linkedin url — linkedin profile url mapped foundation brand person/organization id — a profile id from another altrata brand (boardex, relsci, or wealth x) you can configure multiple methods simultaneously — and should, when possible records that satisfy more methods produce stronger, higher confidence matches 🔴 migrating from a foundation app (boardex, relsci, or wealth x)? read this carefully if your organization is migrating from a legacy altrata foundation app — boardex , relsci , or wealth x — it is strongly recommended to map your existing foundation brand person/org id to the corresponding altrata field on each object the mapping pairs are boardex person id (salesforce) → boardex person id (altrata) boardex organization id (salesforce) → boardex person id (altrata) relsci person id (salesforce) → relsci person id (altrata) relsci organization id ( salesforce) → relsci organization id (altrata) wealth x person id (salesforce) → wealth x person id (altrata) why it matters every record already matched in your foundation app has a foundation brand person / org id stored in salesforce mapping that id into altrata tells the matching engine "this record is already known — preserve the existing match " without this mapping, the bulk match starts from scratch and you risk records re matching to a different altrata profile than they had in the foundation app duplicate matches across legacy and new data loss of identity continuity in reports, dashboards and downstream automations manual cleanup work to reconcile mismatches after the fact action — before running bulk matching open field mapping in the altrata app for each object you use (leads, contacts, accounts, person accounts), locate the foundation brand person id field on the altrata side map it to the salesforce field that currently stores your foundation brand ids save each object tab if you're not sure where your foundation brand person ids live in salesforce, check with the admin who managed your previous foundation app or contact support\@altrata com for help locating them how to configure field mapping from the altrata app, open match settings → field mapping by default, you'll see three object tabs leads , contacts and accounts if your instance has person accounts enabled, person accounts appears as a fourth tab (person accounts are not required ) for each object, review and map fields use the on screen guidance at the top of the page to confirm at least one of the four matching methods is fully configured map any foundation brand id fields (boardex, relsci, wealth x) if you're migrating from one of those apps — see the callout above where the altrata data model has multiple variants of a field (e g , separate personal and professional email fields), map each to the most appropriate salesforce field if your salesforce instance only stores one variant, map it to whichever altrata field best reflects your data save your changes on each tab 3b data filters 🟢 recommended data filters let you control which salesforce records are eligible for altrata matching on a per object basis without filters, every lead, contact, account, and person account in your instance is considered for matching — which can produce noise, unintended bulk matches, and wasted match capacity on records that don't need enrichment (e g , closed lost leads, internal test records, archived contacts) filters apply before the next bulk match begins and improve match quality by narrowing the eligible record pool to what's commercially relevant how to configure data filters from the altrata app, open match settings → data filters for each object — contact , lead , person account , account — enter a filter expression in the input field click save changes filters take effect on the next scheduled or manual bulk match — they do not retroactively unmatch records that have already been matched filter syntax data filters use a soql where clause expression (without the where keyword itself) reference any standard or custom field on the object, combine clauses with and / or, and use standard salesforce operators (=, !=, in, like, etc ) soql filter examples match only leads owned by the sales team owner userrole name = 'sales' match only active contacts with a corporate email domain isdeleted = false and email like '%@%' and email not like '%@gmail com' exclude closed lost or disqualified leads status not in ('closed not converted', 'disqualified', 'unqualified') match only accounts above a revenue threshold annualrevenue >= 10000000 and type = 'customer' limit person accounts to a specific region billingcountry in ('united states', 'canada') and ispersonaccount = true combine multiple criteria — high value, recently active contacts accountid != null and lastactivitydate >= last n days 90 and account annualrevenue > 5000000 ⚠️ validate filter expressions before saving invalid soql will be rejected when you click save test complex expressions in salesforce developer console or workbench first if you're unsure 🟢 best practice start with broad filters that just exclude obvious junk (deleted records, test data, closed lost), run a bulk match, and tighten from there based on what you see in match management over filtering on the first pass risks excluding records you actually wanted matched match settings checklist before moving to the next step, confirm at least one of the four matching methods is fully configured on every object (excluding the account object) you use if migrating from boardex, relsci, or wealth x the foundation brand ids are mapped on every relevant object if your records hold both personal and professional emails each is mapped to its corresponding altrata email field data filters have been reviewed for each object — even if you choose to leave them blank, that should be a deliberate decision you've clicked save on every field mapping object tab and on data filters step 4 — configure page layouts 🟡 required by default, altrata data won't appear on any record pages you need to add altrata components to each page layout where you want users to see altrata data 4a create an altrata tab on each page layout do this for every page layout where altrata data should appear (lead, contact, account, person account) open a record of the relevant type in salesforce click the gear icon in the top right corner, then select edit page in the page editor, click the empty whitespace next to your existing tabs to open the tab editor ⚠️ don't edit your existing details tab only edit the new one at the bottom click add tab in the right hand rail a new details tab is created at the bottom of the list with the new tab selected, open the tab label dropdown and choose custom name it altrata and click done save the page layout 4b add the manual match component 🟢 recommended the altrata link / unlink component lets users manually link a record to (or unlink it from) an altrata profile it's optional but highly recommended in the components search bar, type altrata link unlink drag it onto the page recommended placement the right hand rail (if your layout supports it), or the top of the altrata tab save 4c add altrata data components you have two options for displaying altrata data single component (recommended for most teams) drop in one element that renders the full altrata profile detail individual components drop in components piece by piece if you want fine grained control over which data points appear to add components in the components search bar, type altrata person for leads, contacts, and person accounts altrata account for accounts drag your chosen component(s) into the altrata tab you created save the page layout repeat for every page layout (lead, contact, account, person account) where altrata data should appear step 5 — run the initial bulk match 🟡 required bulk matching is the asynchronous process that connects every eligible salesforce record to its altrata profile after the first run, matches refresh weekly 🛑 do not run bulk matching until field mapping is fully configured this is your last chance to catch missing fields until the next bulk match run (especially the foundation brand person id, if you're migrating from boardex, relsci, or wealth x) open the altrata settings tab from the app launcher click the match management tab click start matching confirm on the pop up the match runs in the background duration depends on the size of your database — 2 3 hours per 100,000 records 🟢 recommended spot check a handful of records once matching completes open a matched lead or contact and confirm the altrata data looks correct if something seems off, review field mapping before troubleshooting individual records