Category:WFM: Difference between revisions

From 3B Knowledge
Jump to navigation Jump to search
(Created page with "3B WFM is a suite of applications tailored for the middle office, including planning, rostering, matching, T&A and timesheeting.")
 
No edit summary
 
Line 1: Line 1:
3B WFM is a suite of applications tailored for the middle office, including planning, rostering, matching, T&A and timesheeting.
3B WFM is a suite of applications tailored for the middle office, including planning, rostering, matching, T&A and timesheeting. This article explores some of the main concepts around setting up and configuring WFM modules (calendar, app, matching, timesheeting).
 
== 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.
 
== 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.

Latest revision as of 02:46, 30 September 2024

3B WFM is a suite of applications tailored for the middle office, including planning, rostering, matching, T&A and timesheeting. This article explores some of the main concepts around setting up and configuring WFM modules (calendar, app, matching, timesheeting).

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.

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.

This category currently contains no pages or media.