Creating and Managing Deliverables in Sentir

Learning Team

Please note: This content is intended for system administrators and is technical in nature. The steps described in this article may not be able to be completed without System Administrator permissions. Please discuss your configuration plans with your Practifi Customer Support Team for their assistance.

Overview

Deliverables help track the entitlements your firm provides to clients across your book of business, giving your team a structured way to monitor service commitments and flag when client obligations are at risk of being missed. Configuring Deliverables well is what ensures the right services are tracked, the right people are notified, and the right activities are created automatically on behalf of your team.

Deliverable configuration lives in the Settings app, under the Servicing category on the Entity Management page. From there, administrators can manage Service Types and their associated Deliverable Types, control who is allowed to edit Deliverable schedules, and configure how Deliverables are assigned across the firm. Deliverable Type setup uses a guided builder that asks plain-language questions and shows a live schedule preview as you work, so you can confirm the schedule looks right before saving. Saving a Deliverable Type and syncing its changes to active Deliverables are separate actions. Save writes the configuration, and notifications on the Deliverable Type record page and the Service Type page let you choose when to push those changes to your live Deliverables.

This article covers which permissions Deliverables rely on, how to configure Deliverable Types, how the save-and-sync model works, how to configure edit permissions, and how to manage exceptions, deactivate Deliverables, and set up activation rules. For information on using and understanding the Deliverable functionality within your organization, please consult our Understanding Deliverables in Sentir article.

Please note: This feature is not automatically enabled within your organization. To enable this functionality or answer any questions regarding this feature, please get in touch with your CSM.

Deliverable Permissions
Deliverable Type Configuration
- Assignment, Including Queues
- Live Schedule Preview
Creating Deliverable Types
Assigning a Deliverable Type to a Queue
The Save and Sync Model
Managing Deliverable Exceptions
- Deliverable Exceptions at the Client Level
Deactivating Deliverables
Creating Activation Rules
- Execute Activation Rules Immediately
- Understanding Activation Rules
Who Can Edit Deliverable Settings?
Understanding the End Deliverable After X Fulfillments Setting
Considerations
Quick Reference

Deliverable Permissions

Deliverables rely on three separate permissions. Users need the right combination of them before the pages and actions described in this article are available to them:

Deliverables User – Provides access to Deliverables and Deliverable Fulfillments.
Manage Deliverable Settings – Required to configure Deliverable Types and Deliverable settings.
Manage Exceptions – Required for the Mark as Exception action.

Please note: Without Deliverables User, the Deliverables and Deliverable Fulfillments options are hidden from the vertical navigation rail on the Records tab, along with the row actions they contain. If a user tells you the actions in this article are missing, check that permission first.

Deliverable Type Configuration

Deliverable Type records are separated into four sections: Basics, Assignment, Schedule, and Fulfillment. You can create new Deliverable Types or view existing ones from the Deliverable Types section of a Service Type record.

For a full explanation of each section's options, see our Understanding Deliverables in Sentir article.

Assignment, Including Queues

The Assignment section, configured at the type level, controls who owns new Deliverables. The available options are Service Owner, Deliverable Type Owner, Entity Owner, Queue, Role, and Business Role. Selecting Queue reveals a Routing Queue picker that lists only queues configured to accept Deliverables, so you can't inadvertently choose one that routing would reject.

Live Schedule Preview

Directly below the How often? question in the Schedule section, a preview shows the next few due dates the current configuration would produce, using a worked example: if a service starts on a given date, the preview lists the next three due dates that would follow.

Creating Deliverable Types

To create a new Deliverable Type in your organization, do the following:

Click the App Launcher and select the Settings app.
From the Settings app, use the Navigation Menu to select Entity Management.
In the left vertical navigation rail, under the Servicing heading, click Service Types.
In the left rail, select the Service Type you want to create Deliverables for. Its details appear in the right pane.
In the Deliverable Types section of the right pane, click the New button.
In the Basics section, enter the following details:
- Name – The name of the Deliverable as you want it displayed.
- Type – Select the Deliverable type from the picklist.
- Status – Deliverables will not be added to new Services if the status is Draft or Inactive. Set this field to Active to make the Deliverable Type available upon saving.
- Description – Enter a detailed explanation of the Deliverable's purpose. End users can view this information in the Description field on the Deliverable record or by hovering over the info icon next to the Deliverable's name in the Task and Event records.
In the Assignment section, select how the Deliverable should be assigned. The Assign to field is set to Service Owner by default. The other available options are Deliverable Type Owner, Entity Owner, Queue, Role, and Business Role. If an Entity lacks a Servicing Team and the Assign to field is set to Role or Business Role, the Deliverable will be assigned to the owner of the related Service.

Please note: For information on assigning a Deliverable Type to a queue, see the Assigning a Deliverable Type to a Queue section below.
In the Schedule section, select Recurring or One-time, then answer the questions that appear.
- For recurring Deliverables, the section asks:
  - How often? – Select Monthly, Quarterly, Semi-annually, Annually, Biennial, Triennial, or an Every N years/months/weeks option (along with a numeric value for N). A live preview appears below showing the next three due dates based on your current settings.
  - When should the first occurrence be? – Choose to anchor the due date to the service start date, to the end of the calendar period the service starts in, or to a specific day within that calendar period.
  - Calculate subsequent due dates from – Select From the previous due date to keep the schedule calendar-aligned, or From the previous fulfillment date to have the schedule follow actual completions.
- For one-time Deliverables, the Schedule section asks a single question: When should it be due? The options are a specific date, a specific calendar date, or a number of days, weeks, or months after the Service starts. Its Deliverables show a schedule reflecting that single due date.
In the Fulfillment section, configure the following:
- Automatically create a task to fulfill this deliverable? – Toggle this on to create a dedicated task each time the Deliverable comes due. When enabled, additional task fields appear:
  - What kind of task? – Choose from: Task Template, Task within a Process, or Reminder Task.
  - How many days before the due date will this task be created? – Enter a whole number. Defaults to 0, meaning the task is created on the due date itself.
  - Can the fulfillment date be changed? – Controls whether users can edit the Fulfillment Date on the Task or Event that fulfills the Deliverable. Options:
    - Yes, until the work item is completed (default)
    - No, never
    - Yes, at any time
  - What if it isn't fulfilled in time? – Options: Skip it and recalculate the next due date (the Deliverable is marked as Missed); Keep it open as overdue (remains open and can still be fulfilled, marked as Fulfilled Late).
    
    Please note: When Automatically create a task to fulfill this deliverable? is turned on, the What if it isn't fulfilled in time? field is locked to Keep it open as overdue.
- End the deliverable after X fulfillments – Toggle this on and enter a whole number in the box to stop the Deliverable from recurring once it's been fulfilled a set number of times. See Understanding the End the Deliverable After X Fulfillments Setting below.
Click Save to finalize the creation of the Deliverable Type. After saving, an unsynced changes notification appears on the Deliverable Type record page (with a Sync button scoped to that type only) and on the Service Type record page (with a Sync button that syncs all unsynced types under that Service Type). For a new Deliverable Type, the sync creates Deliverables on active Services of this type rather than updating existing ones. See The Save and Sync Model below.

Deliverables will be added to Client records, along with the associated Service, upon saving and syncing. To learn more about how Deliverables are fulfilled and adjusted at the client level, consult our Understanding Deliverables in Sentir article.

Assigning a Deliverable Type to a Queue

If you want all Deliverables of a certain type to be assigned to a queue rather than a single user, select Queue in the Assign to field in the Assignment section of the Deliverable Type record. This can be set when creating a new Deliverable Type (see the Assignment step above) or by editing an existing one. To update an existing Deliverable Type's assignment to a queue, do the following:

In the Settings app, use the Navigation Menu to select Entity Management, then click Service Types under the Servicing heading in the left sidebar.
In the left rail, select the Service Type containing the Deliverable Type you want to update.
In the Deliverable Types section of the right pane, click the hyperlinked name of the Deliverable Type you want to update. The Deliverable Type record opens in a new tab.
In the Assignment section, select Queue from the Assign to picklist. A Routing Queue picklist appears.
In the Routing Queue picklist, search for and select the queue you want the Deliverable Type to be assigned to.

Please note: The Routing Queue picklist only lists queues that have been configured to support Deliverables. If the queue you want does not appear, navigate to Setup, then Queues, and add the Deliverable object to that queue's list of supported objects. For more information, see our Creating and Managing Queues in Sentir article.
Click Save to finalize the change.

The Save and Sync Model

Saving a Deliverable Type and syncing its changes to active Deliverables are separate actions. Saving writes your changes to the type's configuration. Notifications then appear at two levels: on the Deliverable Type record page and on the Service Type record page, giving you a Sync button at each level to push those changes to active Deliverables whenever you're ready.

Saving a Deliverable Type

The Deliverable Type record page footer has two buttons: Cancel and Save. Clicking Save writes your changes to the Deliverable Type record. No sync runs at save time. If your changes would affect active Deliverables, unsynced changes notifications appear at both the Deliverable Type and Service Type levels after saving.

Please note: Status-only changes, such as setting a Deliverable Type to Inactive, do not trigger the notification, because they do not require updates to existing Deliverable records.

Unsynced Changes Notifications

When you save a change that would affect active Deliverables, notifications appear at two levels. If a Deliverable Type has no active Deliverables yet, no notification appears. The save is sufficient, and there's nothing to sync.

On the Deliverable Type record page, a notification at the top of the page indicates this specific type has unsynced changes. It includes a Sync button that runs a sync scoped to that one Deliverable Type only. Use this when you want to push a single type's changes immediately without affecting others under the same Service Type.

On the Service Type's record page, when any Deliverable Type under a Service Type has unsynced changes, a notification appears at the top of that Service Type's details on the Entity Management page. It includes a Sync button that runs a service-type-wide sync, applying all unsynced Deliverable Types under that Service Type in a single operation.

For new Deliverable Types, syncing creates Deliverables on active Services of that type. It doesn't update existing records, since none exist yet.

The Sync Confirmation

Clicking Sync, whether from the Deliverable Type's notification or the Service Type's, opens a confirmation screen. The sync can cover all Deliverables except those that have been customized, or all Deliverables, including customized ones, which overwrites their customized settings.

Syncing Customized Deliverables

Customization is tracked per setting rather than across the entire Deliverable. Choosing All deliverables except customized protects each customized setting rather than skipping the whole Deliverable. On a Deliverable with customized settings:

The settings that were changed on it are left as they are
Its remaining settings are updated from its Deliverable Type
It still counts towards the number of Deliverables the sync reports it will update

For example, if a Deliverable's frequency was changed from annual to quarterly and nothing else was changed, that sync keeps the quarterly frequency and refreshes the Deliverable's other settings, such as its description and reminder settings, from its Deliverable Type.

Choosing All deliverables, including customized also overwrites the changed settings, returning the Deliverable to its Deliverable Type's configuration.

The confirmation always asks how each Deliverable's next due date should be updated: recalculate it from today's date, or from the last fulfillment date. Each choice is explained in plain language as it's selected, so it's clear what will happen before anything changes. The confirmation also keeps a count of what the run will do. The sync then runs in the background, and the notification clears when it completes.

While a Sync Is Running

Larger syncs run in the background. While one is in progress, a progress banner on the Service Type page shows how many Deliverables have been updated out of the total. You can continue working while a sync is running. When the sync finishes, you receive a bell notification, and the banner switches to Sync complete, with a link to a Sync Run audit record showing success and failure counts.

Deliverable Sync Batch Scope

Syncs process Deliverables in batches. If your organization regularly syncs large volumes of Deliverables and encounters sync failures or timeouts, contact Practifi Support. They can help you adjust how many Services each batch processes at a time to better suit your organization's data volumes.

Managing Deliverable Exceptions

There are cases when a Deliverable is not fulfilled due to extenuating circumstances, such as a client being unavailable to meet. In such instances, you can mark the affected Deliverable Fulfillment as an exception, which sets its Outcome to Excepted rather than Missed, keeping your reporting accurate. Deliverable Fulfillments are marked as exceptions from the Records tab on a Client record.

Mark as Exception is intended for occurrences that were missed or late. The action appears on every fulfillment, including ones that were already fulfilled on time, so it's worth agreeing internally on when your team should use it.

Please note: To access the Mark as Exception action, users must be assigned the Manage Exceptions permission. For more information, see the Deliverable Permissions section above.

Please note: There is no firm-wide Deliverable Fulfillments view, so fulfillments are reviewed one client at a time from the Client record. To review Deliverables across multiple clients, use the Servicing & Pipeline page.

Deliverable Exceptions at the Client Level

To mark one or more Deliverable Fulfillments as exceptions at the Client record level, do the following:

Open the Client record with the Deliverable Fulfillment(s) you want to mark as exceptions.
Open the Records tab.
In the vertical navigation rail, under the Servicing heading, select the Deliverable Fulfillments option.
In the record list, click the caret on the row of the fulfillment you want to except, then select Mark as Exception. To update several fulfillments at once, select the rows you want, then use the same action to apply one exception to all of them.

Please note: This option will not appear for users who do not have the Manage Exceptions permission.

Please note: If you don't see a caret at the end of each row, the vertical navigation rail is taking up the space the row actions need. Click Hide Views in the Deliverable Fulfillments component header to collapse the rail and bring the carets into view.
In the Mark as Exception window, enter a reason in the Exception Reason field.
Click the Excepted By field and search for and select the user making the exception.
Click Save. The fulfillment's Outcome is set to Excepted.

Deactivating Deliverables

When Deliverables are not needed, you can handle this in a few ways:

Complete or cancel individual Deliverables within a Service
Cancel all Deliverables within a Service
Deactivate the Deliverable Type so new Deliverables will no longer be copied over to new Services

Please note: When clients are marked as lost using the Mark As Lost Client action, their Deliverables are automatically deactivated.

Completing or Canceling Deliverables

Completing a Deliverable sets its status to Completed, while canceling it sets its status to Canceled. When a Deliverable's status is set to Completed or Canceled, the following things happen:

The Deliverable no longer appears on Task and Event records.
The Next Due Date field's current value is deleted and stops recalculating.
Fulfillment activities are not created.

Deliverable cancellation follows this logic:

When a Service is canceled, its related Deliverables are canceled as well.
When a Deliverable's status is set to Canceled, the following actions occur:
- It no longer appears in Tasks and Events as available for fulfillment.
- Any Tasks and Events previously associated with the canceled Deliverable can now fulfill other Deliverables.
- If the Task was a pre-nominated fulfillment activity previously linked to the canceled Deliverable, it will also be canceled.
- The Next Due Date field's current value is deleted and is not recalculated.
- Fulfillment activities are not generated.

The Complete Deliverable and Cancel Deliverable actions are available in three places: on the Deliverables record list on a Client record, on the Servicing & Pipeline page, and on the Deliverable record itself. They appear while the Deliverable's status is Active. Once it is Completed or Canceled, the option becomes Reactivate Deliverable.

Please note: These actions are not available on Tasks. A Task is related work created to fulfill a Deliverable, not the Deliverable itself, so cancel the Deliverable from the Deliverables list rather than from the Task.

To complete or cancel an individual Deliverable:

Open the Client record with the Deliverable you want to complete or cancel.
Open the Records tab.
In the vertical navigation rail, under the Servicing heading, select the Deliverables option.
In the record list, click the caret on the row for the desired Deliverable, then select Complete Deliverable or Cancel Deliverable.
In the pop-up window, click to confirm that you want to complete or cancel the Deliverable.

To complete or cancel multiple Deliverables in a list view:

Check the boxes next to the Deliverables you want to complete or cancel.
Click the caret on the Add Work pill and select Complete or Cancel Deliverables.
In the pop-up window, click to confirm that you want to complete or cancel the Deliverables.

Reactivating Deliverables

If you want to restore one or more completed or canceled Deliverables, you can reactivate them. The Reactivate Deliverable action is available on Deliverable records and as a row action or mass action for Deliverables with a status of Completed or Canceled. In the row actions, it takes the place of Complete Deliverable and Cancel Deliverable once the Deliverable is no longer Active.

The Reactivate Deliverable action changes the Deliverable's status from Completed or Canceled to Active. Attempting to reactivate a Deliverable that already has an Active status will result in an error.

Please note: Reactivating a Deliverable means it will become available for fulfillment on Tasks and Events, will start generating fulfillment activities (if enabled), and its Next Due Date field will be recalculated. If the calculation basis is the Service's start date, today's date will be used instead.

Alternatively, you can manually set the due date in the Reactivate Deliverables window using the Next Due Date field.

Canceling All Deliverables Within a Service

To cancel all Deliverables within a Service for a given Entity, use the Cancel Services action:

Open the Entity record whose Service you want to cancel.
Open the Records tab, then, in the vertical navigation rail, under the Servicing heading, select the Services option.
In the record list, click the caret on the row for the Service, then select Cancel Service.
A prompt asks you to confirm you want to cancel all related Deliverables. Click Cancel.

Setting Deliverable Types as Inactive

If you no longer want Deliverables of a certain type to be copied over into new Services, you can deactivate the Deliverable Type in the Servicing settings page:

In the Settings app, navigate to Entity Management > Service Types.
In the left rail, select the Service Type containing the Deliverable Type you want to deactivate.
In the Deliverable Types section, click the hyperlinked name of the Deliverable Type. The Deliverable Type record opens in a new tab.
In the Basics section, click the pencil icon.
Click the Status picklist and select Inactive.
Click Save at the bottom of the screen.

Creating Activation Rules

Because not all clients need the same level of service, your firm might want to tailor Deliverables to fit different client segments. Deliverables can be activated automatically when specific criteria are met, for example:

If Client Segment = Platinum, activate the Quarterly Review Deliverable
If Client Segment = Gold, activate the Semi-Annual Review Deliverable
If Client Segment = Silver or Bronze, activate the Annual Review Deliverable

Administrators can create one or more rules using the Activation Rules tab on Deliverable Type records. The Activation Rules tab works the same way as the Rule Builder components found within Active Forms and the Rulebook. Read our article on Understanding and Using the Rule Builder in Sentir to learn more.

To add activation rules to a Deliverable Type record:

In the Settings app, navigate to Entity Management > Service Types.
In the left rail, select the Service Type containing the Deliverable Type you want to edit.
In the Deliverable Types section, click the hyperlinked name of the Deliverable Type you want to edit. Its record page opens in a new tab.
On the Deliverable Type record, click the Activation Rules tab.
On the Activation Rules tab, define the rule(s) you want to apply, then click Save.
Click back to the Service Type record.
When you return to the Service Type, if there are unsynced changes, a notification appears at the top of the detail pane. Click Sync in the notification to push the updated activation rules to active Deliverables.

Execute Activation Rules Immediately

If you don't want to wait for the system's nightly job to evaluate activation rules, you can run them on demand at the individual Deliverable level. Do the following:

Open the Client record with the Deliverable you want to evaluate.
Open the Records tab.
In the vertical navigation rail, under the Servicing heading, select the Deliverables option.
Click the name of the desired Deliverable.
On the Deliverable record, click the caret at the end of the button row and select Execute Activation Rule.

Understanding Activation Rules

Activation rules cause Deliverable statuses to change based on whether the rule criteria are met. Note the following about activation rule logic:

When activation rules are added to Deliverables, the system checks them with a nightly scheduled job.

If the rule conditions are true, the Deliverable's status is set to Active, and it behaves like normal.
If the rule conditions are false, the Deliverable's status is set to Inactive.

Inactive Deliverables behave the same way as Deliverables with a status of Completed or Canceled:

They don't appear in the sidebar assistant on Tasks and Events.
Their Next Due Date field is blank.
Their fulfillment activities aren't created.

As with other Deliverable settings, a local copy of the Deliverable Type's activation rules is stored on the Deliverable record itself, so that bespoke changes can be made if necessary.

Every night, a job runs that evaluates all active and inactive Deliverables against their activation rules.

If the Deliverable is active and its activation rules are true, nothing happens.
If the Deliverable is active and its activation rules are false, its status is set to Inactive.
If the Deliverable is inactive and its activation rules are true, its status is set to Active.
If the Deliverable is inactive and its activation rules are false, nothing happens.
If the Deliverable is Marked for Fulfillment and its activation rules are false, its status is set to Inactive.

When the activation rule is evaluated and passed, resulting in the Deliverable's status being set to Active, the following happens:

The Deliverable starts appearing in the sidebar assistant on Tasks and Events again.
The Next Due Date field is calculated. This calculation follows the same logic as when the Deliverable was initially created, using the Initial Calculation Basis on the Deliverable Type. However, if the Basis is Service Start Date, the reactivation date (today's date) is used instead.
Fulfillment Activity Creation: Once the due date is calculated, fulfillment activities should be created according to the configured criteria.
- Immediate Fulfillment Activity Creation: If the Deliverable's status is set to Active today and the time between today and the Deliverable's due date is less than the interval specified for the fulfillment activity (i.e., Days Before Due Date on the Deliverable Type record), then the respective fulfillment activity is created immediately after the Deliverable becomes active.
- Scheduled Fulfillment Activity Creation: If the time between today and the Deliverable's due date is greater than or equal to the interval specified for the fulfillment activity, the respective fulfillment activity will be created by the DeliverableFulfillmentActivityService scheduled job, which runs nightly.
Status Update: The Deliverable's status will be changed from Active to Marked for Fulfillment if the scheduled job causes the creation of a fulfillment activity.
Manual Fulfillment: If an active Deliverable is manually marked for fulfillment by the user clicking the plus icon next to it on the sidebar of a Task or Event record, its status is updated from Active to Marked for Fulfillment.

When the activation rule is evaluated, resulting in the Deliverable's status being set from Active to Inactive, the following happens:

The Deliverable doesn't appear in the sidebar assistant on Tasks and Events.
Its Next Due Date field is blank.
Its fulfillment activities aren't created.

When the activation rule is evaluated, resulting in the Deliverable's status being set from Marked for Fulfillment to Inactive, the following happens:

The Deliverable doesn't appear in the sidebar assistant on Tasks and Events.
Its Next Due Date field is blank.
Its fulfillment activities aren't created.

Who Can Edit Deliverable Settings?

A multi-select picklist called Who can edit Deliverable settings? controls which users can modify a Deliverable's schedule. A user can edit a Deliverable's schedule if they match any of the selected options:

Administrators (System Administrator profile)
Users with the Manage Deliverable Settings permission
Deliverable owners (the user who owns that specific Deliverable)
Any user

By default, this setting is set to Administrators and Users with the Manage Deliverable Settings permission. Admins can change it at any time, firm-wide or per Service Type.

The setting applies to all Service Types unless it's overridden at the Service Type level. Editing a Service Type's configuration shows the same control, pre-filled with the current firm-wide selection, and admins can make a different selection for that Service Type.

Understanding the End Deliverable After X Fulfillments Setting

This setting's initial value is specified by the administrator on the Deliverable Type record and copied across to the Deliverable upon initial creation.
Whenever a Deliverable Fulfillment record is created or edited, the value in the parent Deliverable's End Deliverable after X fulfillments setting is compared to the number of Deliverable Fulfillment records where the Outcome is either Fulfilled On Time or Fulfilled Late.
If the setting's value is less than or equal to the count of eligible records and the Deliverable's Status is Marked for Fulfillment, then it's set to Completed.

Please note: Whenever a Deliverable is marked for fulfillment, its status changes from Active to Marked for Fulfillment. When the setting's value is evaluated against the fulfillment records, the system checks whether the Deliverable's status is Marked for Fulfillment and then sets it to Completed.
If the setting's value is greater than the count of eligible records and the Deliverable's status is Completed, then it's set to Active.

Considerations

Please note the following known behaviors:

Entity Management pages and sync notifications may need a browser refresh to reflect the latest state after Deliverables are created or synced.
A brand new Deliverable Type's rollout notification appears on the Deliverable Type page but may not appear on the Service Type page until the type is edited or synced.
There is no firm-wide Deliverable Fulfillments view. Fulfillments are reviewed from the Client record, one client at a time. Deliverables themselves can be reviewed across clients from the Servicing & Pipeline page.

Quick Reference

I Want To...	Go To...
Configure Service Types or Deliverable Types	Entity Management > Servicing > Service Types
Set who can edit Deliverable schedules firm-wide	Entity Management > Servicing > Settings
Override edit permissions for one Service Type	Select the Service Type, then its Who can edit Deliverable settings? override
Edit a Deliverable Type's schedule	Service Type > Deliverable Types list > click the type name
Route new Deliverables to a team queue	Deliverable Type > Assignment > Assign to > Queue
Push a single type's changes to active Deliverables	Deliverable Type record page > Unsynced changes notification > Sync
Push all unsynced types under a Service Type to active Deliverables	Service Type detail pane > Unsynced changes notification > Sync
Review the results of a completed sync	Sync complete banner > Sync Run record
View and manage one client's Deliverables	Client record > Records > Servicing > Deliverables
Check whether individual occurrences were fulfilled, missed, or excepted	Client record > Records > Servicing > Deliverable Fulfillments
Mark a fulfillment as an exception	Client record > Records > Servicing > Deliverable Fulfillments > row caret > Mark as Exception
Cancel a single Deliverable	Client record > Records > Servicing > Deliverables > row caret > Cancel Deliverable
View Deliverables across multiple clients	Servicing & Pipeline
Review the full history and related work for one Deliverable	The Deliverable record
Adjust the sync batch size	Contact Practifi Support