Implementation Guidance for Motivate

The following section provides recommendations and guidance regarding the configuration of specific areas of the application within the customer's Salesforce.com org. This section is intended to detail any specific functionality within these areas that Administrators need to be aware of prior to deploying the Motivate application within their organisation.

Web Browsers

Web browsers supported by the Salesforce.com Salesforce Classic User Interface can be used by Motivate end users (i.e. Players, Observers & Influencers). Only web browsers supported by the Salesforce.com Lightning Experience User Interface are supported for Motivate Administrators (i.e. Motivation Designers and Competition Managers). For all supported web browsers, JavaScript, cookies and SSL 3.0 must each be enabled. For further details on Salesforce.com supported browsers, please see: https://help.salesforce.com/articleView?id=getstart_browser_overview.htm

In addition, Google Chrome is the only supported browser for Motivation Designers launching and displaying Inspire Channels.

Recommendations

The following list provides recommendations of the limits of specific components in the Motivate application. While it is possible to exceed these limits, it is recommended that they be adhered to in order for end users to receive the best user interface experience and for the Motivate application to operate correctly.

• Maximum recommended Score that should be awarded to a user is up to 9,999
• Maximum recommended Score that should be set on a Base Behaviour is 99
• Maximum recommended number of characters that make up a Level Name is 16-20
• Maximum recommended number of characters that make up a Badge Name is 16-20
• Maximum number of words that make up a Competition or Experience Group Name is 4
• Maximum value set on the "Max Rewards" field is 998
• Maximum number of members in a Member Template, Competition or Experience Group is 9,995
• Maximum number of Reward records that a User, Competition or Experience Group may have is 40,000

Queues

Queues can be created that contain one or more users that in turn help teams manage the distribution of Leads within an org. When new Lead records are created within the org, the owner of the Lead can be manually or automatically (see Assignment Rules below) assigned to an individual user, or to a pre-defined queue.

If Lead records are created that fulfil a Behaviour which, in turn, awards the OwnerID of the record, a Reward will be awarded to the owner of that Lead record. However, Motivate only supports the awarding of Rewards to OwnerIDs that are Users (not Queues). Any active Behaviours that award on the recipient OwnerID will not, therefore, generate Rewards if the Lead record is owned by a Queue. Rewards will only be generated for a single User and not to the members of a Queue.

Assignment Rules

Assignment Rules can be set up to automate the assignment of Lead record ownership to users or queues based on criteria or formulae that equate to true. It is possible for Base Behaviours to be created that have the recipient of the Reward set as the Owner ID. This means that when a record is created that matches the Base Behaviour criteria, the Reward that is created will be awarded to the Owner ID of that record.

It is, therefore, possible to trigger the assignment of ownership of a Lead record to a user or to a queue and the creation of a Reward at the same time as the criteria is met. In such a situation, a Base Behaviour's criteria will be assessed (and Rewards will be created) before any active Assignment rules are triggered whose criteria match that Base Behaviour's criteria. Thus, the Reward will always be awarded to the user who created the record regardless of ownership assignment that is specified on the Assignment Rule. Care should therefore be taken when creating Assignment Rules and Base Behaviours that trigger on the same criteria IF the Reward recipient is set as the Owner ID on the Base Behaviour.

Non-Chatter and Community Users

Chatter can be enabled or disabled via Permission Sets or Profiles using the 'Enable Chatter' System Permission. Motivate provides the ability to add all the members of a competition into a Chatter Group that is linked to a competition. This feature is not available for Non-Chatter users as they do not have access to Chatter and, thus, cannot be members of Chatter Groups. Additionally, Community users cannot be added to Chatter Groups created outside the Community space.

In addition, users without access to Chatter will not be able to access their profile in the Sub Tab App because it is integrated into Chatter. This is typically where the Motivate, Rewards, Behaviours and Competitions subtabs are placed. However, non-Chatter users can still access these components via the "Motivate" page found on the tab bar or "All Tabs" list. The Motivate page provides non-Chatter users full access to the Motivate Player user interface. Lastly, the audience participation features available in Inspire require the use of Chatter for audience members to send participation requests. Inspire can be run without these features if required.

Logout Session Timeout Setting with Inspire

For orgs that have the Session Timeout setting "Force logout on session timeout" enabled, it should be noted that only one tab should be left running in the browser (i.e. the one displaying the Inspire Channel itself). If additional tabs are left logged in to Salesforce these will be logged out after the period of time specified in "Timeout Value" has elapsed (i.e. as dictated by the "Force logout on session timeout" setting). This will also log out the session in any other tabs that were logged in to the same Salesforce org at that time. The login session for the Inspire Channel will, therefore, also be logged out with the result that it will no longer be able to retrieve any further information. To reduce the likelihood of this occurring, 'launching' the Channel using the "Launch Inspire" tab will now open the Channel in the same browser tab (rather than opening it in a separate tab). Note that it will still be possible to launch the Inspire Channel in a separate tab using the 'Launch' link within the Channels section of the Administration page. This can, therefore, be used by customers that have not enabled the “Force logout on session timeout” security option.

Scheduled Behaviour SOQL Queries

When using Scheduled Behaviours, Motivation Designers are required to define the SOQL query that the Assessment Engine will use when the query is executed. The query is executed to a schedule that is defined using CRON expressions (a time-based job scheduling utility). There are two types of query that can be used with Scheduled Behaviours, Standard (Non-Aggregated) and Aggregated.

Standard (Non-Aggregated) Queries

Standard queries expect two fields to be selected and the position (order) of each field in the query is critical. A "User ID" field must be the first field and a Numeric "Value" field (that is to be used by the Assessment Engine) must be the second field.

For example:

SELECT id, CustomNumericField__c FROM User

Aggregated Queries

As with standard queries, aggregated queries expect a User ID field and a Numeric value field. However, these are constructed using aliases and must follow a naming convention where "User" is the alias of the User ID field and "Value" is the alias of the Numeric value returned by the second field used by the Assessment Engine.

It's good practice to include a filter to ensure the aggregate result set doesn't contain any records where the User is "null", which can help improve performance by reducing the likelihood of running into governor limits.

For example:

SELECT OwnerId User, SUM(Amount) Value FROM Opportunity WHERE OwnerId != null GROUP BY OwnerId

Special Variables

You may use the variable "runFromDate" in the queries as a tokened variable that can form part of the Behaviour criteria. This variable will contain the date/time the Behaviour was last run. Using this variable allows a query to be constructed that might for example only select data that has been updated since the last scheduled run i.e.:

SELECT createdById User, COUNT(id) Value FROM Task WHERE LastModifiedDate >: runFromDate GROUP BY createdById

Filtering out Queues

Only Users can receive rewards, so for customers that utilise Queues, any Scheduled Behaviours where the results could include both User and Queue IDs must be restricted to only return User IDs. This can be achieved by adding a 'WHERE' clause containing: Owner.Type = 'User' in the query.

Salesforce Objects that may be assigned to Queues are: Cases, Leads, Orders, Service Contracts, Knowledge Article Versions and Custom Objects.

An example based on the Case object might look as follows:

SELECT OwnerId User, COUNT(Id) Value FROM Case WHERE Status = 'Closed' AND Owner.Type = 'User' GROUP BY OwnerId