App Loaders: Difference between revisions

From 3B Knowledge
Jump to navigation Jump to search
(Created page with "Application loaders are used to load auxiliary records to support the context definition. == Scheduler == To set up app loaders for the scheduler, go to Setup -> Custom Metadata -> Scheduler Loaders == Candidate App / Timesheeting / Terminal == To set up app loaders for the scheduler, go to Setup -> Custom Metadata -> Component Loaders == Object Name == The scheduler app loader follows the same pattern as the App Definition - you need to set the correct Object...")
(No difference)

Revision as of 23:37, 4 December 2024

Application loaders are used to load auxiliary records to support the context definition.

Scheduler

To set up app loaders for the scheduler, go to Setup -> Custom Metadata -> Scheduler Loaders

Candidate App / Timesheeting / Terminal

To set up app loaders for the scheduler, go to Setup -> Custom Metadata -> Component Loaders

Object Name

The scheduler app loader follows the same pattern as the App Definition - you need to set the correct Object Name or leave it blank for global context

Component Loaders for Component Configuration

Component loaders need to be linked to the relevant component configuration record.

Global Variables

Explore the WFM Context article to learn about the global variables available for your loader

Loader Setup

Within the Javascript Code field, you need to add your javascript loader definition.

A sample Contacts loader for Account Context scheduler:

{
    name: "contacts",
    objectName: "Contact",
    filterRecordsBy: function () {
        return "Id IN (SELECT b3o__Candidate__c FROM b3o__Placement__c WHERE b3o__Job__r.b3o__Client_Account__c = {0})"
    },
    groupRecordsBy: "Id",
    fieldToLoad: ['Name', 'LastName', 'FirstName'],
    filteringItems: function () {
        return [
            `'${contextRecordId}'`,`'${contextRecord.Id}'`,
            events, 
            fetchInfo, 
            contextRecordId, 
            contactUserId, 
            userId, 
            contextObjectName, 
            contextRecord, 
            contextUser
        ]
    }
}

Both Component and Scheduler loaders inherit the global variables which you can use in your filter logic.

Footprint

{
    name: "",   //Must be unique name for the loader. You will reference it in the app definition
    objectName: "",     // Must be the API name of the object to query
    filterRecordsBy: function () {
        return ""   //Return a string or array of strings SOQL filters
    },
    groupRecordsBy: "Id",   //Optional grouping field to group the results by
    fieldToLoad: [],    //An array of field names/paths to load
    filteringItems: function () {   
        return [
            `'${contextRecordId}'`,`'${contextRecord.Id}'`,
            events, 
            fetchInfo, 
            contextRecordId, 
            contactUserId, 
            userId, 
            contextObjectName, 
            contextRecord, 
            contextUser
        ]
    }
}

Limits

Although we have ensured you can load an unlimited number of records in a loader, it is not usually a good practice as it may slow down the application. Please apply relevant filters to the SOQL filter.