528
edits
Category:WFM: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(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. | |||