Worker Mobile App Definition

The worker mobile app relies on the Component Configuration of the type “Clock In / Out Component” as well as on the Component Loader linked to the created Component Configuration.

The schedulable objects for the worker mobile app are as follows:

• Break (b3s__Break__c) - represents a shift break
• Expense (b3s__Expense__c) - represents an expense item
• Request (b3s__Employee_Request__c) - represents an availability request
• geoTag (b3s__Geo_Tag__c) - represents a location tag for clock in/out
• Invitation (b3s__Invitation__c) - represents a shift invitation
• Shift (b3s__Shift__c) - represents a shift

Global Properties

In addition, the definition has the following global properties (outside the schedulable scope)

"canAddBreaks":true,	//whether or not user can create a break
"canAddExpenses":true,	//wather or not user can add expenses
"canAddShifts":true,	//whether or not user can create shifts
"canAddAvailability":true,	//whether or not a user can log availability
"isGPSRequired":true,	//whether or not GPS access is required. If set to true, the user MUST grant access to GPS, otherwise, they can't start a shift.

Object Properties

The shift, request and expense schedulables add the following properties

"lookBackLimitDays":14	//How many days in the past to load data for
"lookForwardLimitDays":14	//How many days in the fuure to load data for

The request schedulable introduces the following properties

"typeFieldPath":"b3s__Type__c",	//The field responsible for providing the type of the request (available/unavailable)
"canEdit":null,	//a selector logic that determines if the request can be edited
"canDelete":null,//a selector logic that determines if the request can be deleted

Conditional Properties

You can request a candidate to complete fields before/after shift start using the actionForms property in the definition:

{
    "schedulable": {
        "shift": {
            ...,
            "actionForms": {
                "startShift": {
                    "recordFormFields": [
                        {
                           "field":"b3s__Comments__c",
                           "type":"field-text-area",
                           "required":false,
                           "disabled":false
                        },
                        {
                           "field":"",
                           "labelOverride": "Upload",
                           "type":"field-file-upload",
                           "props": {
                                "placeholder": "Upload File",
                                "maxFileSize": 1000000
                            },

                           "required":false,
                           "disabled":false
                        }
                    ]
                },
                "endShift": {
                    "recordFormFields": [
                        {
                           "field":"b3s__Comments__c",
                           "type":"field-text-area",
                           "required":false,
                           "disabled":false
                        },
                        {
                           "field":"",
                           "labelOverride": "Upload",
                           "type":"field-file-upload",
                           "props": {
                                "placeholder": "Upload File",
                                "maxFileSize": 1000000
                            },

                           "required":false,
                           "disabled":false
                        }
                    ]
                }
             },

             ...
        }
    }
}

The geotag schedulable usually doesn’t require any changes. Here’s the base template:

"geoTag":{
    "objectType":"b3s__Geo_Tag__c",
    "shiftFieldPath":"b3s__Shift__c",
    "latitudeFieldPath":"b3s__Location__latitude__s",
    "longitudeFieldPath":"b3s__Location__longitude__s",
    "timeFieldPath":"b3s__Tag_Time__c",
    "typeFieldPath":"b3s__Type__c",
    "locationErrorPath": "b3s__Location_Error__c"
}

The invitations schedulable introduces two conditionals: canAccept and canReject (similar to the timesheet approval schedulable). These conditionals determine when a shift invitation can be accepted or rejected and hide/show the buttons accordingly.

"invitation":{
 ...
 "canAccept":{
    "condition":{
       "allOrSome":"all",
       "selectors":[
          {
             "field":"b3s__Status__c",
             "operator":"notequals",
             "value":"Accepted"
          },
       ]
    }
 },
 "canReject":{
    "condition":{
       "allOrSome":"all",
       "selectors":[
          {
             "field":"b3s__Status__c",
             "operator":"notequals",
             "value":"Rejected"
          }
       ]
    }
 },
}

The shift schedulable also has the following:

• canStartShift - requires a selector
• canFinishShift - requires a selector

{
	schedulable: {
		shift: {
			....
			canStartShift: {
                condition: {
                    allOrSome: 'all',
                    selectors: [
                        {
                            field: 'Id',
                            operator: 'isnull',
                            value: false,
                        },
                    ],
                },
            },
            canFinishShift: {
                condition: {
                    allOrSome: 'all',
                    selectors: [
                        {
                            field: 'Id',
                            operator: 'isnull',
                            value: false,
                        },
                    ],
                },
            },
}
}
}

So, if you want to disable Clock In/Out, simply do this:

{
	schedulable: {
		shift: {
			....
			canStartShift: {
                condition: {
                    allOrSome: 'all',
                    selectors: [
                        {
                            field: 'Id',
                            operator: 'isnull',
                            value: true,	//<== impossible, thus always false
                        },
                    ],
                },
            },
            canFinishShift: {
                condition: {
                    allOrSome: 'all',
                    selectors: [
                        {
                            field: 'Id',
                            operator: 'isnull',
                            value: true, //<== impossible, thus always false

                        },
                    ],
                },
            },
}
}
}

Adding navigation items

You can add additional navigation items to the Candidate WFM app by defining a global schema property navMenuItems that accepts an array

• label - the label of the button
• href - can be a portal page name, a portal event (e.g. @logout event or page name #Index) or external link (must be HTTPS)
• target - when external link is added, the target allows us do define how the new page will be opened

navMenuItems: [
	//This will open a portal page with the name Timesheet_Submission
    { label: 'Timesheet', href: '#Timesheet_Submission?contactId=:userId' },
//This will navigate to an external link
    { label: 'Google', href: 'https://www.google.com', target: '_self' },
]