WFM Context

App context is important for identifying the context in which the component is embedded, and it is derived from the id URL parameter (auto-populated when the record is embedded in on a record). The context is available in the schema through the ":contextId" syntax. In schedule loaders, the context can be retrieved using the "contextRecordId" global variable. In addition, you can access the currently logged in user via “:contactUserId” or “:userId” which returns the logged in user’s id.

Further to this, from version 1.8+, you have access to all of the fields on the contextRecord and the contextUser. This means that you can use the following merge tags in your schedule definitions:

• :contextId - this will be the contextual record's id.
• :contactUserId - this will be the contextual user's id.
• :userId - this will be the contextual user's id.
• :contextRecord.Id, :contextRecord.AccountId, etc - this will extract the first level fields from the context record
• :contextUser.Id, :contextUser.Name, etc - this will extract the first level fields from the context user
• :contextDate - available for action forms, this will be the start date of the schedulable record

Data Loaders

Data loaders will inherit the following global variables which you can use to filter out relevant records with:

events => a list of loaded events
fetchInfo => an object with start/end dates defining the loaded period
contextRecordId => the id of the context record
contactUserId => the id of the context record
userId => the id of the context record
contextObjectName, => the API name of the contextual record
contextRecord => the entire context record with all first-level fields
contextUser =>the entire context record with all first-level fields

Component / Schedule Definition

You can use merge contexts in the definitions file like so:

{
    schedulable: {
        expense: {
            objectType: 'b3s__Expense__c',
            startFieldPath: 'b3s__Date_of_Expense__c',
            endFieldPath: 'b3s__Date_of_Expense__c',
            selectionClause: ['b3s__Contact__c = :contextRecord.Id'],
            contactFieldPath: 'b3s__Contact__c',
            lookBackLimitDays: 14,
            lookForwardLimitDays: 14,
            recordFormFields: [
                {
                    field: 'b3s__Date_of_Expense__c',
                    labelOverride: 'Date of Expense',
                    type: 'field-date-input',
                    default: ':contextDate',
                    required: true,
                    disabled: false,
                },
                {
                    field: 'b3s__Contact__c',
                    type: 'field-select',
                    required: false,
                    disabled: true,
                    default: ':contextUser.Id',
                    loader: 'contacts',
                    optionLabelField: 'Name',
                },
            ]
        }
    }
}

Context User

Across the scheduler, timesheeting and clock in/out apps, we can identify the logged in user globally by accessing  the variables “:contactUserId” or “:userId” which returns the logged in user’s id - which is the Contact Id. In a digital experience, we automatically identify the logged in user based on the context user, however in a guest user environment (e.g. in Portals or Visualforce), you can pass a contactId and/or sessionKey URL parameter. Note that if you pass a contactId or sessionKey parameter and the context is a Digital Experience, we will ignore the logged in user and will instead utilize the passed contactId/sessionKey.