Data Model

Table of Contents
1. Overview
1.1. Referral object
1.2. Partner Referral object
1.3. Partner object
1.4. Microsoft Solution objects
1.5. Log object
1.6. WorkSpan Test Object

1. Overview

In WorkSpan, Referral Opportunities represent an offer from a company to its partner to collaborate in selling something to a third party (‘Customer’). If we are offering an opportunity to our partner, then it’s an ‘Outgoing’ Referral. If they are offering to us, then it’s an ‘Incoming’ Referral. A Referral Opportunity record is shared between the partners: some fields can only be edited by the originating party, some by both parties, and some fields are the same for both parties, but each has its own version that only they can edit, while the partner’s counterpart fields are read-only for them (or even invisible, depending on configuration). The receiving party can Accept or Decline the Referral Opportunity at any moment.

The WorkSpan Salesforce package contains seven custom objects, five of which are for the business, one for the admins, and the last one is 100% technical. All the fields, validation rules, and help texts are outlined in the SF Field Dictionary.

1.1. Referral object

This is the main business object. The Referral object in Salesforce represents an offer from a company to its partner to collaborate on an Opportunity. It stores the shared data between the parties and our half of the counterpart fields.

1.1.1. Referral Record Types

There are multiple Record Types on a Referral, divided into two categories: ‘Outgoing’ and ‘Incoming’. The users can only create the former, and the latter is only created by the integration.
The Record Types are further divided into use case-specific categories (e.g. the Amazon (AWS) flows have ‘Incoming Amazon’ and ‘Outgoing Amazon’, and Microsoft Partner Center (MPC) flows have ‘Incoming Microsoft’ and ‘Outgoing Microsoft’), in order to provide dedicated layouts for each case.

1.1.2. Data collection fields

All Record Types on all Referrals have a ‘Referral Creation Method’ field that is populated automatically depending on how the Referral was created. If the Referral was bulk created (See here), the value should be ‘Bulk’; if the Referral was created using automation (See here), the value should be ‘Flow’; and if the Referral was created manually from the interface, the value should be ‘UI’.

1.2. Partner Referral object

The Partner Referral object represents the other half of the counterpart fields controlled by the partner in WorkSpan. They are not supposed to be populated or edited in Salesforce. 

So, a combination of Referrals plus related Partner Referral records in Salesforce represents a Referral Opportunity in WorkSpan.

1.2.1. Partner Referral object global search enablement

Since Partner Referral is a different object than the Referral object, the user cannot use global search to find the Referrals by the values of the Partner Referrals fields they have.

To enable a global search for the Partner Referral, the following steps must be performed:

1. Open ‘Einstein’ from the right panel of the  ‘Setup’ page.
2. Click ‘Einstein Search’ and proceed to  ‘Object to Always Search (beta).’
3. In the ‘Assign Search Object’ section, choose the profiles that will use the ‘Object to Always Search’ feature.
4. Click on the drop-down menu icon next to the profile that needs to use global search and click ‘Edit’.
5. On the new ‘Edit Object for Standard User’ window, search for the ‘Partner Referrals’ in the right column, select ‘Partner Referrals’ and then click on the arrow icon. Then click ‘Save’.

Note that ‘Object to Always Search (beta)’ is a beta feature. It means that until Salesforce officially releases it, it has to be enabled in every org where the feature is required to be used. It can also be removed from the Salesforce functionality without any additional notification.

1.3. Partner object

We also have the Partner object that stores a Partner ID that WorkSpan uses to identify the companies involved. Two Partner records (‘Amazon’ and ‘Microsoft’) are created OOTB by a post-installation script.

Do not edit Partner ID values of already existing Partner records. Create new records with the proper ID instead.

1.4. Microsoft Solution objects

The Microsoft Partner Center (MPC) flows (refer here) are supported by a pair of dedicated objects because MPC requires Solution IDs to be associated with Referrals with a many-to-many cardinality. The objects have identical labels (“Microsoft Solutions”) for better UX in the related lists. Thus this guide will use API names to distinguish between the two objects when necessary.

1.4.1. Main MicrosoftSolution__c object

This object stores Microsoft Solution ID that the MPC requires. These Solutions are linked to Referral Opportunities via the junction ReferralMicrosoftSolution__c object.

Do not editSolution ID values of already existing MicrosoftSolution__c records. Create new records with the proper ID instead. If you already have Referral records related to the Solution with the ID that you want to substitute, then:

1.4.2. Junction ReferralMicrosoftSolution__c object

This is the junction object that links Microsoft Solutions to Referral Opportunities, which is required for the Microsoft Partner Center (MPC) use case. Due to sharing considerations, the relationship between this object and the main object is a Lookup, not Master Detail.

1.5. Log object

This is an event logging object for admins that can help debug possible issues. See Logs for more details.

1.6. WorkSpan Test Object 

This object exists only to provide test coverage for common trigger methods. It should only be populated in tests and never contain data in production. There is no need for any user (admin or not) to interact with it.