What it Does

This job is not an actual SF scheduled job. Instead, it's actually just a Non Call Policy residing within the backend organisation that AVS is activated against.

How it Works

The CRO policy gets created each time this "job" is enabled, and then deleted each time this "job" is disabled.

The start component in the CRO policy will always be "Call Log Capture" which is a component developed specifically to support CRO uploads. Call Log Capture ensures that the CRO policy is triggered after every single call in the org, regardless of how the call has been initiated.
This policy processes the call and then sends the data to Salesforce for creating the CRO record.

Frequency

Because it is not an actual Salesforce job, the frequency doesn’t exist. It can be enabled or disabled.

Requirements

The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• Not the case

Does this job need to be running?

In order for the CROs to be created, the job needs to be running.

What it Does

This job creates Hourly Call Reporting (HCRO) records to provide statistics on activity. A record is created per hour for each user that has been involved in a call during that hour (either as the From user or the To user).

How it Works

Starting the job from the Admin Home page places the HCRO job in the scheduled queue. When it reaches the scheduled time to run, the job runs as a synchronous method. After the job completes, it reschedules itself to run again after five minutes. Errors will be added as nbavs__ErrorLog__c records with a location of ‘HCRO Processing’.

The method queries all nbavs__CallReporting__c (CRO) records which are not yet processed (where the value of the nbavs__HCRO__c field is false). It summarises metrics around talk time and number of calls. It then inserts an nbavs__Hourly_Call_Reporting__c record for each user that has been involved in a call during that hour. Once each CRO record is processed, it will be marked as such by setting the value of the nbavs__HCRO__c field to true.

Frequency

Every five minutes.

Requirements

The org must have either a CTI or Contact Centre licence. The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• Each run of the job consumes one asynchronous job towards the daily limit.

• No callouts are made.

Does this job need to be running?

If you are not planning to use Hourly Call Reporting metrics, you do not need to run this job. However, you may not be able to retrieve information from the period that the job is inactive, if you wish to use this information in the future.

What it Does

This job takes historical data on users’ changes in availability profile and state, and creates nbavs__AvailabilityLog__c records to represent this data in Salesforce. This allows you to report on this information.

How it Works

Starting the job from the Admin Home page places the Availability Logs job in the scheduled queue. When it reaches the scheduled time to run, the job runs as a queueable method which allows callouts.

The queueable method makes a callout to our backend to get the most recent availability history for the org. We store the DateTime that the job last ran in a protected custom setting, so we only retrieve the most recent data. The job inserts an nbavs__AvailabilityLog__c record for each time a user has changed their availability state.

Once the job is complete, it reschedules itself to run again in five minutes. This ensures the most up-to-date data.

Any errors will be logged in the nbavs__ErrorLog__c object with a location including the words ‘Availability Logs’.

Frequency

If there is no availability log information, the job only runs every 30 minutes to check for updates. If there is new information, the job runs every five minutes.

Requirements

The org must have a Contact Centre licence. The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• Each run of the job consumes two asynchronous jobs towards the daily limit. One is scheduled, and the other is queueable.

• The Availability Logs job makes one external callout per run.

Does this job need to be running?

If you are not planning to use Availability Log metrics, you do not need to run this job. However, you will not be able to retrieve information from the period that the job is inactive, if you wish to use this information in the future (see Known issues).

Known Issues

We store the most recent DateTime that the Availability Logs job was run in a protected custom setting. If the job is inactive for an extended period of time, this may causes issues when it is reactivated as it is attempting to retrieve an enormous amount of data. If this happens in your org, contact Natterbox Customer Support and provide all relevant information to resolve. It is likely that we will not be able to pull the availability history from the period that the job was inactive into Salesforce.

What it Does

This job takes backend data about call queue usage and creates nbavs__Call_Queue_Log__c records to summarise metrics about call queue usage.

How it Works

Starting the job from the Admin Home page places the Call Queue Logs job in the scheduled queue. When it reaches the scheduled time to run, the job runs as a batch job with a batch size of 50.

The batch job queries nbavs__Call_Queue__c records. For each call queue a callout is made to the backend to retrieve data about call queue history. We store the DateTime that the job last ran in a protected custom setting, so we only retrieve the most recent data, generally any created within the last five minutes. The job then checks if there is a Call Queue Log record already created containing metrics for that specific call queue during that hour. If there is, it updates the record with the new data. If not, it inserts a new nbavs__Call_Queue_Log__c record for each call queue which has been active within that specific hour, containing metrics about the call queue’s usage during that hour.

Once the job is complete, it reschedules itself to run again in five minutes. Any errors will be logged in the nbavs__ErrorLog__c object with a location containing the words ‘Call Queue’.

Frequency

Every five minutes.

Requirements

The org must have a Contact Centre licence. The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• Each run of the Call Queue Logs scheduled job (where there are call queue records in the org) consumes at least four asynchronous jobs towards the daily limit. If the org has more than 50 call queues, more asynchronous jobs will be created.

• Each batch can make up to 50 external callouts.

Does this job need to be running?

If you are not planning to use Call Queue Log metrics, you do not need to run this job. However, you will not be able to retrieve information from the period that the job is inactive, if you wish to use this information in the future, and you may experience issues when trying to run the job after a period of inactivity.

What it Does

This job synchronizes user service presence status. It ensures that the user statuses in Salesforce reflect the correct login/logout states for Omni-Channel service presence groups. The job checks user statuses and updates the corresponding group memberships based on their availability in the system.

How it Works

When the job is triggered from the scheduled context, it runs as a background process.
It first checks if Omni-Channel is enabled in the Salesforce organization. If not, the job exits early. It fetches user details, mapping user IDs to their statuses. The job retrieves the current service presence statuses of users from Salesforce. Any users flagged as unsynced from the last job run are queried. It checks if the statuses of users need updating based on their current availability and performs necessary updates in both systems. Any errors encountered during processing are logged in an error list, which will trigger an exception if not empty.
Upon completion, the job automatically reschedules itself to run again after a specified interval.

Frequency

Every 5 minutes.

Requirements

The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• The job is designed to process a maximum of 50,000 records per run.

• The job makes one external callout per run.

Does this job need to be running?

If your organisation uses Omni-Channel, this job needs to be running.

What it Does

This job fixes fields on nbavs__CallReporting__c records that relate to wrapups (nbavs__Wrapup_Duration__c, nbavs__WrapupCode_0__c, nbavs__WrapupCode_1__c, nbavs__WrapupLabel_0__c, nbavs__WrapupLabel_1__c, nbavs__WrapupString_0__c, nbavs__WrapupString_1__c) that may have been incorrectly set.

How it Works

Starting the job from the Admin Home page places the Wrapup Fixer job in the scheduled queue. When it reaches the scheduled time to run, the job runs as a batch job with a batch size of 50.

The batch job iterates over the nbavs__TempTask__c object. It first queries nbavs__CallReporting (CRO) records which relate to these Temp Task records. Then it takes data, stored as JSON on the Temp Task record, and updates the wrapup fields on the relevant CRO record. The job updates the CRO records, then deletes the processed Temp Task records.

Any errors will be logged in nbavs__ErrorLog__c records with a location of ‘ScheduleCROFixesInstance’.

Frequency

Every five minutes.

Requirements

The org must have either a CTI or Contact Centre licence. The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• Each run of the Wrapup Fixer scheduled job (where there are Temp Task records in the org) consumes at least four asynchronous jobs towards the daily limit. If the org has more than 50 Temp Tasks, more asynchronous jobs will be created.

• No external callouts are made.

Does this job need to be running?

The Wrapup Fixer scheduled job fixes a specific issue where nbavs__CallReporting__c records are missing values in the wrapup fields. If you observe this issue whilst the job is not running, start the job. Otherwise, you do not need to have this job running.

What it Does

This job is specific to the Dial Lists feature. It removes invalid and completed dial items from dial lists, adds new items to dynamic lists, creates summary reports, sorts and audits dial items.

How it Works

Starting the job from the Admin Home page places the DDL job in the scheduled queue. When it reaches the scheduled time to run, the job runs as a batch job with a batch size of 2000.

The DDL job runs with six states, each responsible for performing functions on different data.

• ‘Clean’ queries nbavs__DialItem__c records where the state is ‘Retry’, ‘Preview’ or ‘Pending’ and determines which are still meet the criteria to be in the list view. The records that are no longer in the list view are deleted and an nbavs__DialItemAudit__c record is inserted for each dial item to record the action.

• ‘Completed’ queries nbavs__DialItem__c records where the state is ‘Completed’, ‘Uncontactable’ or ‘Invalid’. For each dial item, it inserts an nbavs__DialItemCompleted__c record and deletes the nbavs__DialItem__c record. An nbavs__DialItemAudit__c record is inserted for each dial item to record the transfer from active to completed.

• ‘Refresh’ queries nbavs__DialItem__c records where the state is ‘Preview’, ‘Pending’, ‘Active’ or ‘Selected’. It checks if these items are invalid (which here means that both the primary and secondary phone fields are empty) and updates their state.

• ‘Report’ queries both nbavs__DialItem__c and nbavs__DialItemCompleted__c records. It generates metrics about the records, then inserts an nbavs__DialListReport__c record for each Dial List containing the metrics about that Dial List’s items. This means that you can run reports to see trends over time.

• ‘List View Sort’ sorts Dial Items by updating the records with new values for the nbavs__OrderId__c field.

• ‘Clean Audit Log’ queries nbavs__DialItemAudit__c records. If there are more than 250000, it deletes the oldest audit logs in batches of 2000 until there are fewer than 250000. Additionally, if any Dial Lists have phone fields which are inaccessible, these are disabled.

Once the job is complete, it reschedules itself to run again in five minutes. Any errors are logged in the nbavs__ErrorLog__c object.

Frequency

Every five minutes.

Requirements

The org must have either a CTI or Contact Centre licence. The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• Each run of the scheduled job adds a minimum of six asynchronous jobs towards the daily limit. This increases once multiple Dial Lists, each containing multiple Dial Items, are added. To calculate an approximate value, use the formula ‘5n + 4’ (where n = number of Dial Lists) to get the number of asynchronous jobs added to the daily limit per run of the scheduled job.

• No external callouts are made.

Does this job need to be running?

If you are not using the Dial Lists feature, you do not need to start this scheduled job. If you are using the feature, this job needs to be running or you will not receive the data you need.

What it Does

This job is specific to the Insight feature and will only be shown if Insight is enabled within the org. It populates nbavs__Insights__c records with analysis data obtained from an external service.

How it Works

Starting the job from the Admin Home page places the Insight job in the scheduled queue. When it reaches the scheduled time to run, the job runs as a batch job with a batch size of 10.

The batch job queries nbavs__Insights__c records which have not yet been processed (where any of these fields are ‘Pending’: nbavs__Status_Transcription_Download__c, nbavs__Status_TalkTime_Download__c or nbavs__Status_CallFlow_Download__c). For each record, it retrieves the analysis data from an external service. The data is mapped to fields on the Insight record, and the record is updated. Additionally, nbavs__Insight_Category__c and nbavs__Insight_Conversation__c child records are inserted based on the retrieved data.

Once the job is complete, it reschedules itself to run again in five minutes. Errors are logged as records in the nbavs__ErrorLog__c object, and errors related to a specific Insight record are inserted as nbavs__Insights_Failure__c records.

Frequency

Every five minutes.

Requirements

The org must have a Contact Centre licence and an Insight licence. The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• The Insight job consumes a minimum of four asynchronous jobs towards the daily limit per run. This includes one scheduled job and a minimum of three batch-type asynchronous jobs (one for start, one for execute and one for finish). With more than 10 Insight records to process, the number of asynchronous jobs increases.

• Each run of the job makes several external callouts. For each Insight record, three calls are made to obtain the necessary information.

Does this job need to be running?

If you are not using the Insight feature, you do not need to start this scheduled job. If you are using the feature, this job needs to be running or you will not receive the data you need.

What it Does

It processes records from the DialList__c object, calculates statistics based on related DialItem__c and DialItemCompleted__c records, and stores the results in the DialListReport__c object.

How it Works

When the job is scheduled from the Salesforce setup, it is added to the scheduled job queue. Once the scheduled time arrives, the job runs as a batch process, working through the records in chunks of 200.

The batch job queries the DialList__c object to find all shared and active Dial Lists that are set to generate reports. These are typically lists that contain dynamic content and have items either completed or still in progress.

For each Dial List, if it contains a custom SOQL query (ListViewSOQL__c), the system rewrites that query to count the related records, which helps determine the total scope of that list. The job then checks the related Dial Items and groups them into various categories, such as:

• Unreachable

• Completed

• Retry

• In Progress

• Pending

• Invalid

It uses these counts to update or create a new DialListReport__c record for each Dial List, capturing important metrics about the list's performance and the status of its items.

Once all the records in the current batch are processed, the system calculates any remaining items that haven’t been completed and updates the report. The job then repeats for the next batch of 200 records until all Dial Lists have been processed.

Any errors will be logged in the ErrorLog__c object.

Frequency

Every hour.

Requirements

The org must have a Contact Centre licence. The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• Each run of the job consumes one asynchronous job towards the daily limit.

• No callouts are made.

Does this job need to be running?

If you are not using the Dial Lists feature, you do not need to start this scheduled job. If you are using the feature and also want the reports, this job needs to be running or you will not receive the data you need.

What it Does

Is designed to manage and link Salesforce records in the CallReporting__c object that are related to call transfers. Specifically, it identifies call records with certain transfer flags (From_Flag_Blind_Transfer__c, From_Flag_Attended_Transfer__c, etc.) set to true and attempts to associate these flagged records with other call records based on UUIDs. The related call records are then linked via the Related_Call_Reporting__c field.

How it Works

When the job is scheduled, it enters Salesforce’s scheduled job queue. Once the scheduled time arrives, the job runs as a batch process, processing records in chunks of 2,000 to ensure efficient handling of larger datasets.

The batch job queries the CallReporting__c object to retrieve records created within the last two months that have one or more transfer flags set to true. These records are likely related to call transfers and are not yet linked to other records.

For each batch of records:

1. Initial Transfer Record Identification:

   • The system identifies unique From_UUID__c and To_UUID__c values from transfer-flagged records and stores these in sets for efficient lookups.

   • It then performs a secondary query to retrieve related CallReporting__c records without transfer flags but that share a From_UUID__c or To_UUID__c with the flagged records. These additional records are collected into a list alongside the flagged transfer records.

2. Mapping and Grouping Transfers:

   • The job organizes the records in the list into groups, where the key is a unique combination of From_UUID__c and To_UUID__c.

   • For each group, the job designates the first (earliest) record as the "initial call" for that transfer. Subsequent records in the group are marked as related to this initial call by updating the Related_Call_Reporting__c field.

3. Update and Error Handling:

   • The system updates all related records.

   • Errors encountered during this process are logged in the ErrorLog__c object, ensuring that any issues can be reviewed and resolved without impacting the batch as a whole.

Once each batch completes, the job continues with the next 2,000 records until all relevant CallReporting__c records have been processed and relationships have been established.

Frequency

Every hour.

Requirements

The user who starts the job must have the NBVC Administrator PermissionSet. They must retain this permission for as long as the job is active. If the user has their permissions revoked, or is deactivated, then another user with the correct permissions must stop and restart the job.

Limits and Allowances

• Each run of the batch job consumes one asynchronous job towards the daily limit.

• The batch processes records in chunks of 2,000.

• No callouts are made.

Does this job need to be running?

If your organization frequently handles call transfers and relies on linking related records for reporting or analytics, this job is likely essential.