​

1. Setup Assistant​

As an Integration Admin, I need to set up and configure the application​.

​

For customers to have a good experience while setting up the application on Salesforce, we provide a way to easily complete the steps required. To streamline the setup process and ensure the high adaption of the Trax created a single flow for customers to complete. This will take a matter of minutes as opposed to several days and will be as simple as following a guided wizard rather than following a long installation instruction document.​

​

​

​

​

2. Data Mapping Step​

As an Integration Admin, I need to map my unique Salesforce and Trax schemas​. ​

 

Since the application will be performing an ongoing outbound synchronization of Trax master data entities and a post visit inbound synchronization of the KPIs calculated on the Trax platform, a data mapping layer is implemented to inform the solution where to query the master data entities, and where to deposit the KPI data. The data mapper is provided as a component on the Trax_Project object for the Integration Admin to complete. ​ ​

 

 

 

 

3. Master Data Synchronization ​

As an Integration Admin, I need the Master Data Entity data to synchronize between Trax and Salesforce​

​

When mapped master data entities are created or updated in Salesforce, they will be synchronized with Trax via the batch job that can be scheduled. The job will first dynamically query the appropriate objects, based on what has been configured in the Data Mapping Step, and then check for any records that have been updated since the last run time.​ ​ Only the delta will be sent to Trax.
 

3.1.Store data exchange

Minimum of 2 level account/store hierarchy required, i.e. Parent account - child account or Parent account - child retail store. The Trax visit / Trax task will take place on the child level, the account team, account owner and their managers are considered on the parent level.

Store creation, update and disabling logic:

• Store exists in SF but does not exist in Trax. Action: Create store in Trax

• Store exits in Trax but not in SF. Action: Deactivate store.

• Store with same attributes exists in both systems. Action: no action

• Same store exists in both systems but some of its attributes are different (e.g., region). Action: update store in Trax

​

3.2. User data exchange

• Role hierarchy

  • Based on the Salesforce standard role hierarchy, the users assigned (directly or implicitly) to stores in Salesforce will be automatically synced to the relevant Trax Project.

  • In some scenarios additional users who are outside the account team and the role hierarchy need access to Trax. We call them ‘HQ users’ and they are not assigned directly or implicitly to any of the stores but need to have Trax access. If the Salesforce org includes multiple markets/countries, the users need to be assigned to the relevant Trax Project record in Salesforce so that the integration is informed of what data should be sent to which Trax Project. To do so, the Salesforce admin needs to assign these users to the relevant Trax Project. HQ users can be assigned to multiple Trax projects at the same time. Note that HQ users will not be able to carry out mobile visits.​

• User creation, update and disabling logic:

  • User exists in SF but not in Trax. Action: create it in Trax

  • User exits in Trax but not in SF. Action: No action.

  • User exists in both systems. Action: No action.

  • Same user exists in both systems but some of its attributes are different (e.g., last name). Action: Update it in Trax.

  • If the user is deleted from Salesforce or removed from the Trax project or the Trax Permission Set is revoked, the user will be disabled in Trax.

​

3.3. Routes data exchange

Route: In Trax, we can assign users to list of stores. This assignment is called route. Only users with routes are allowed to carry out mobile visits in the Trax application.

• Role hierarchy management: The solution supports the standard Salesforce role hierarchy to create routes. Route creation is required in Trax to be able to carry out mobile visits. The solution will define routes for the Account team members, Account Owners and their managers assuming all the above-mentioned pre-requisites for user creating are met. (See figure in the previous chapter)

• Route creation, update and disabling logic:

  • Route exists in SF but not in Trax. Action: create it in Trax

  • Route exits in Trax but not in SF. Action: Deactivate routes

  • Route exists in both systems. Action: No action.

  • Same route exists in both systems but some of its attributes are different. Action: update it in Trax.

​

​

4. Batch Scheduler Step​

As an Integration Admin, I need to schedule the synchronization batch job to run regularly.

​

• A step is included in the setup assistant that allows the user to set the frequency at which their instance of Salesforce makes callouts to synchronize the master data entities. The step allows the user to select a frequency of for the batch job to run. Additionally, the step displays other batch jobs that are scheduled so that the user can make an informed decision about what level of frequency makes sense for their instance of Salesforce.​ ​ ​

• The Batch Data Sync job may not execute if the your Salesforce org has more than 100 jobs pending in the Apex Flex Queue. Unexpected behavior may occur if this limit is exceeded. 

​

​

5. Post Visit Inbound Data Synchronization ​

As an Integration Admin, I need the data generated by a visit to synchronize into Salesforce.

​

• When visits are completed by field representatives, the images and data they collected in the Trax mobile app are sent to Trax for processing and saved for retrieval.

• KPI Section: The solution ensures that all the fields in the “KPI” object of the Trax Analysis Result JSON will be synchronized from Trax to Salesforce. 

• Out of the box, the package will map the KPI results from Trax to the new landing pad object. Users can override individual field mappings if they desire, and they can completely override the mapping to take full control of the data flow.

• Data flow:

  • A landing pad object will contain the entire Trax KPI Payload. When records of this object are created, a user defined flow can create the appropriate record(s) for your chosen model, and then relate that record to the appropriate sub-records.

  • The implementation task consists of creating a record-triggered flow (or Apex trigger if you are comfortable with Salesforce development). The flow should operate when new records are created on the landing pad object. The flow should take the values populated in the landing pad object to create record(s) of KPI results in whichever object you use to track them in your org. You should inspect the payload to determine if you have the data necessary to relate that record to the appropriate retail store, visit, product, account, question, etc

• Flow implementation: ​

  • ​The landing pad object doesn’t have relationships with the various CGC Base and Enhanced Data Model objects that are relevant to KPI Results, namely Visit, Question (JobDefinition), and Product. Therefore, users will be required to create their own custom Flows or Triggers to create the VisitJob or RetailVisitKpi records, with their appropriate relationships.

  • For users not utilizing Consumer Goods Cloud, two recommended approaches are available for implementing KPI Results:

    • Use the Landing Pad Object: Users can employ the landing pad object as-is to deposit results. The context provided in the deep link to the Trax Mobile application can be leveraged to associate the record with the relevant Visit, Retail Store, Account, etc. This association is achieved by constructing a flow that runs when Trax KPI Records are created or updated.

    • Use a Custom Object + Flow: In cases where users are already monitoring KPI results with a custom object, and if this object lacks complex relationships, they might directly update their data mapper to align with their custom object. Subsequently, a record-triggered flow can be implemented to associate the record with the appropriate Account, Retail Store, Visit, or Product

​

​

6. Notifier Configuration Step​

As an Integration Admin, I need to configure Salesforce to receive inbound webhooks from Trax​ to receive KPI data real-time.

​

A step is provided that allows the user to subscribe to Trax API calls and receive KPI data. The API calls pass through the middleware and create logs in the Salesforce org. Users can view KPI data in the object records they designated in the data mapping step.​ ​ ​

​

​

7. Package Logging Configuration Step​

As an Integration Admin, I need to configure the package log levels and limits​.

​

To improve the reliability of the app, the package includes debug logging capabilities and a setup assistant section to manage the settings of the debug logger. A custom object called Package Logs will be included in the package, records of which can be viewed from the setup app in a custom object tab. ​

​

​

8. Server-to-Server Authentication​

As an Integration Admin, I need to allow Salesforce to make outbound API calls into the Trax application​.

​

For Salesforce instances to perform API callouts into Trax, a step is included in the setup assistant that collects an API Key from the user. The step instructs the user to generate the API Key in X-Suite. Additionally, an input is be provided within the step for the user to enter their Trax Project Name, which is passed in each API call.​ ​ ​

​

​

​

9.Mobile Deep Link Setup

Mobile deep link significantly improves the mobile user experience during switching between the Salesforce and Trax mobile apps to capture shelf images. The use of deep link is highly recommended due to the structure of routes (i.e., every route will have one Salesforce Account (e.g., CVS) that includes one or multiple stores (e.g., CVS Boston, CVS Chicago etc.). So, in some cases, without having the deep link the sales rep may need to switch routes quite frequently and manually.

​

9.1. Deep Link to Trax Mobile App​

As a Field Representative, I need to open the Trax mobile app from a Salesforce retail store visit page​.

​

Consumer Goods Cloud and Sales Cloud customers have different methods by which they will deep link to the Trax application, and both will be powered by separate Lightning Web Components. The components will both check for iOS or Android context and construct the URL in the appropriate format as detailed in the Trax Documentation. A call-back URL will also be provided, which will return the user to where they left off in the Salesforce mobile application once the session concludes​. ​ ​

​

9.2.Instructions​ for Admins

As an Integration Admin, I need to add the deep link actions to my record pages in Salesforce​.

Consumer Goods Cloud (CGC) customers and Sales Cloud customers will have a different experience setting up the deep link functionality, but both require some configuration from the Integration Admin user. A step will be provided in the setup assistant that shows instructions for both experiences. ​

 

Known deep linking limitations of CGC mobile app:

• Since the deep link will be implemented via the Mobile Links feature of CGC, the admin will be provided instructions in the setup wizard to configure their mobile links and add them to the Quick Access section of the Store Cockpit. Implication: Trax will not be listed among the tasks.

• Only store level deep link is possible​.

• Users cannot be assigned to multiple Trax projects.

• Users cannot have multiple visit types​.

 

Known deep linking limitations of SF1 mobile app:

• SF1 app needs to be online to be able to generate the deeplink URL.

• Only store level deep link is possible​.

• Users cannot be assigned to multiple Trax projects.

• Users cannot have multiple visit types​.

 

10.User Authentication

User login/authentication is not part of deep link and not part of the AppEx solution. The mobile user needs to log in to the Trax app to be able to capture images.  We provide 2 ways to authenticate:

1. Trax username and Trax password: The username comes from Salesforce and it must be a valid email address. During the configuration the Salesforce Admins need to map what field in Salesforce shall be the username in Trax (e.g., the email address of the user should be the username in Trax). Once the user is created, the user receives an email from Trax to set up the password. 

2. Single-Sign On (SSO): Optional. Trax provides Authentication Integration Services that allow users to achieve this. Trax supports the OAUTH 2.0 protocol with the following Authentication Servers: AFDS, SFDC, Okta, Ping Federate. Documentation here. Please note that the user doesn't need to authenticate every time when he/she wants to capture images Trax session and password expiry can be configured. Please contact your Trax Account team for details. Once the user logged in to Trax mobile app, the user can smoothly switch between the Salesforce and the Trax mobile app via deep link.