Only this pageAll pages
Powered by GitBook
1 of 95

Admin Guide

Loading...

Getting Started

Loading...

Loading...

Loading...

Loading...

Data

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

System Processes

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Support at Home

Loading...

Integrations

Loading...

Loading...

Loading...

Loading...

Loading...

Settings

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Welcome to Maica Administration

How is our Knowledge Base structured?

Our Knowledge Base is divided into two main sections:

  • The User Guide

  • The Administration Guide.

This structure is designed to meet the needs of different types of users within the organisation. The User Guide provides easy-to-follow instructions for everyday users who work with the application, while the Administration Guide offers more technical information for administrators and power users responsible for configuring and maintaining the system. This setup ensures that each user can quickly access relevant resources based on their role and responsibilities.

In order to switch between the two guides, simply use the dropdown in the top left corner of your screen.

Administration Guide Overview

The Administration Guide is tailored for system administrators and technical users responsible for the more complex aspects of Maica. It includes detailed instructions on system configurations, integrations (e.g., with Stripe and Xero), managing permissions, and customising the platform to meet organisational needs. This guide is useful for users who manage settings, troubleshoot issues, and maintain the overall functionality of Maica. If your role involves system setup, user management, or advanced configurations, the Admin Guide provides the technical details you need.

Discover Maica Administration

More Resources


Data Objects

Learn about the key Data Objects in Maica and their associated Validation Rules and Logic.

Salesforce Hosting

Learn how to check that your Salesforce instance is hosted in Australia.

System Processes

Discover how key Automation and Logic Processes work within Maica

Reference Data

Understand how to use and import the Reference Data Template successfully into your Maica instance.

Integrations

Discover the Integrations available within Maica and how to configure them within your instance.

Settings

Learn what all the Settings with Maica control and how they can help improve your workflow.

Schedule a Demo

Schedule a 30 minute demo to see if Maica is for you.

Request a Trial

Try Maica today!

Partners

Partner with Maica and join a network dedicated to enhancing care delivery.

Checklist

The Checklist object in Maica is used to manage task lists for users, either before, during, or after shifts and appointments including the ability to include external links.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Checklist object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Checklist Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Checklist Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Checklist Start Date Cannot Be After End Date

Ensures that the Checklist Start Date cannot be after the End Date.

Validation Rule Detail

Rule Name

VAL_CHECKLIST_0001

Error Message

VAL_0001: The Start Date cannot be after the End Date.

Error Location

Start Date

Error Condition Formula
maica_cc__Start_Date__c > maica_cc__End_Date__c

Client Note

The Client Note object in Maica represent Notes that are taken on behalf of the Participant/Client.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Client Note object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Client Note Schema.

Timesheet Entry

Timesheet Entries are used to track the hours worked by a Resource for a particular service within a particular Appointment.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Timesheet Entry object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Timesheet Entry Schema.

Find your Maica Edition

Learn how to find which Edition of Maica your organisation is using

The following article describes the process of checking which Maica Edition your organisation is using.

Step 1: Open Installed Packages

  1. Navigate to Salesforce Setup.

  2. In the Search bar, type "Installed Packages".

  3. Click on Installed Packages from the search results.

Step 2: Locate Your Maica Edition

  1. In the Installed Packages list, look for any packages with "Maica" in the name.

  2. Your Maica edition(s) will be listed here

  3. The available Maica options are:

    • Maica Client Delivery

    • Maica Client Care

    • Maica Client Management

Check out the guide below to watch each step in real time.

Data Objects

Learn about the Data Objects used in Maica.

What is included in this section?

This section contains a list of Maica's primary Data Objects. Each Data Object has its own page which contains information on the following:

The information below is generic and applies to each object.

Fields & Relationships

On each object page you will find a table that provides a comprehensive overview of all Fields and Relationships for the relevant object in Maica. It includes all Fields related to the object, detailing their names, labels and formulas. Additionally, it outlines the various relationships this object has with other objects, such as lookup and master-detail relationships.

Validation Rules

On each object page, there will be a list that outlines the Validation Rules applied to the relevant object in Maica. Within each rule, you will find the Rule Name, Error Message, Error Location and Error Condition Formula.

You can deactivate the Validation Rules if they interfere with your business processes, but be mindful that this may affect Maica processes and/or result in data issues. We do not recommend deactivating the Validation Rules.

Flows

On each object page, you will find a list of associated Flows that are relevant to that particular object in Maica. Within each Flow, you will find a Summary of the Flow, the API Name, Label and Type of Flow. In addition, you will find a technical description and breakdown of how the Flow is working in Maica.

You can clone and alter Flows as your business processes need; however, please ensure that any changes are thoroughly tested before deployment. Flow modifications can have an impact on Maica processes and/or cause data difficulties.

You can deactivate Flows if they interfere with your business processes, but be mindful that this may affect Maica processes and/or result in data issues. We do not recommend deactivating the Validation Rules.

Trigger Handlers

On each object page, you will find a list of associated Trigger Handlers that are relevant to that particular object in Maica. Within each Trigger, you will find a Summary of the Trigger, the Label and Load Order. In addition, you will find a technical description and breakdown of how the Execution. Logic & Outcome of the Trigger in Maica.

Availability

The Availability Object in Maica is used to define the available working hours for a Resource, i.e. when they are able to work.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Availability object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Availability Schema.

Timesheet

Timesheets are used to track the hours worked by a Resource.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Timesheet object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Timesheet Schema.

Log

This object in Maica manages the Log level details of automated processes supporting the Maica package.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Log object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Log Schema.

Preference

The Preference object in Maica captures the Client/Participant preferences when receiving your services.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Preference object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Payment Request Schema.

Aged Care

Learn about Aged Care Claim Management Settings in Maica

The Home Care Package (HCP) claim process and settings will soon be replaced by Maica’s upcoming Support at Home upgrades. This section is currently under review and will be updated following the release of the new functionality on 1 July 2025.

Fields & Relationships
Validation Rules
Flows
Trigger Handlers

Reference Data

Learn about Reference Data in Maica

What is Reference Data?

Reference Data is essentially any flat/static data that is used across Maica to power it's functionality. This data is consistent, predefined, and used throughout the system to standardise operations and prepare your Maica instance for Service Delivery.

Why is it important?

Reference data is important for Service Delivery in Maica because it populates and powers key functions like Appointments, Billing, and Rostering. For example, you cannot schedule an Appointment without having the necessary Reference Data, such as Resources.

So where do I begin?

There are two distinct stages in the Reference Data lifecycle within Maica, these are:

  1. Populating Reference Data Templates

  2. Importing Reference Data

Both these stages are critical in the successful import of Reference Data into Maica. To learn more about each stage, please refer to the related articles linked above.

Claim Management

Learn about Claim Management Settings in Maica

These settings determine how Maica manages all Claims and their function throughout the application.

To dive deeper into either NDIS or Aged Care Claim Settings, please visit their specific pages linked below:

  1. NDIS Claiming

  2. Aged Care Claiming

Validation Management

Learn about Validation Management Settings in Maica

These settings determine how Maica manages Validation and its function throughout the application. Please refer to the below table for more information on each setting:

Setting
Description

Enforce Availability for Appointments

This setting switches on (or off) the capability to enforce resource availability when creating or managing Appointments. This means, if the selected resources don't have an availbility record for the time of the Appointment, Maica will prevent the Appointment from being created.

Enforce Availability for Timesheets

This setting switches on (or off) the capability to enforce resource availability when creating or managing Timesheets. This means, if the selected resources don't have an availability record for the time of the Timesheet, Maica will prevent the Timesheet from being created.

Availability Consideration

This toggle controls how Maica determines if a Resource is available when assigning them to appointments.

ON: Maica will only consider Resources as available if they have an Availability record set up for that day.

OFF: Maica assumes Resources are available by default unless an Unavailability record explicitly states otherwise.

here
here
here
here

Support Category

Represents the NIDS Support Category a Support Items or Service Booking may be associated with.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Support Category object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Support Category Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Shift Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Category Number and Support Purpose Required When Category Source is NDIS

Ensures that a Category Number and Support Purpose is provided when the Category Source is NDIS.

Validation Rule Detail

Rule Name

VAL_SUPPORT_CATEGORY_0001

Error Message

VAL_0001: Please ensure that Category Number and Support Purpose are provided when the Category Source is NDIS.

Error Location

Top of Page

Error Condition Formula
AND(
  ISPICKVAL(maica_cc__Funding_Source__c, "NDIS"),
  OR(
    ISPICKVAL(maica_cc__Support_Purpose__c, ""),
    ISBLANK(maica_cc__Category_Number__c)
  )
)

Travel Claiming and Expenses

Learn about how Maica automates the generation of travel claiming and expenses.

Maica offers the capability to automate the generation of travel billing records as well as expenses for Resources. This includes dealing with time-based and non time-based travel components as well as a number settings that determine how travel is managed within Maica.

Maica's Travel Mangement Process

This diagram represents a workflow related to managing travel information and expenses, particularly in relation to invoicing.

  1. Start: The process begins with either the User or Google providing input into the system (possibly related to travel data).

  2. Travel Information: This step gathers the necessary travel information, which then splits into different possible paths:

    • Time-Based Travel Settings: These settings include rules or restrictions related to time, such as specific dates or durations of travel.

    • Travel Caps: There might be limits or caps in place, such as restrictions based on Apprentice Program, Client Types, Virtual Staffing, or Service Agreements. These caps ensure that travel expenses do not exceed certain thresholds.

  3. Invoice Line Item: Once all the travel information and related settings are gathered, the next step is generating an Invoice Line Item. This represents the cost associated with the travel being recorded as a specific item for invoicing.

  4. Resource Expense: Following the invoice creation, the expenses related to travel are assigned as Resource Expenses and captured against the Resource who delivered the service.

  5. Invoice: The final step involves generating an Invoice that includes all the necessary travel line items, accounting for time-based travel settings and any caps applied. This invoice is the official document for charging the relevant party for the travel expenses.

  6. End: The process completes with the expenses and invoices being finalized.

The "Invoice Line Item" is generated based on all the travel-related settings, ensuring compliance with time-based travel rules, caps, and service agreements.

In summary, this diagram outlines a process of collecting travel-related data, applying any relevant restrictions or caps, and finally generating invoice line items that reflect travel expenses to be billed.

NDIS Support Catalogue

Learn how to Import NDIS Support Catalogues into Maica

How do I import an NDIS Support Catalogue?

This is an extension of the Data Import Utility article. Please read the previous article before continuing on to this one. You can access it immediately by clicking here.

1. Select Flow Setting and Upload your File

The first step of importing an NDIS Support Catalogue is identical to any other Data Import and is explained here. This article will continue based on the assumption that these steps have been completed.

2. Configure your Import

Once you have clicked Import, you will have the ability to configure your import to your preference. This is where you may specify which Price Lists you want Maica to make for you, as well as offer a useful description for future reference, as shown below.

It is our recommendation to select a description comparable to the period covered by the Support Catalogue, or the filename of the actual CSV file received from the NDIS website for clarity.

3. Confirm and Process

Once you have configured your import, simply click Confirm to start the Import Process. The data from the NDIS Support Catalogue File will be interpreted by the NDIS Import Support Items Catalogue Flow in Maica and processed.

As part of the import, you should understand how your data will be altered. Once done, your Support Item and Price List data will be changed as follows:

  • Any new Support Item in the NDIS Support Catalogue will be created as a new Support Item in Maica

  • Any existing Support Item in the NDIS Support Catalogue that is updated, i.e the Name is changed, will update the existing (corresponding) Support Item record in Maica.

    • The records are matched based on the Support Item Number as this is in the file and on the Support Item record in Maica.

  • As part of the import process, Maica will create new Price List records for each of the Areas selected in Step 2.

    • The created Price List record(s) will have the following name format: NDIS Supports {STATE} ({CREATED DATE})

    • Example: NDIS Supports VIC 25/10/2022

  • Each of the Support Item records created or updated by the import will be added to the new Price List(s) so it can be used whenever this Price List is selected in Maica

For any import errors, the Support Item record will need to be created or updated manually and added to the necessary Price List(s).

Timesheet Generation

Learn about how Maica automates the generation of timesheet activities for Resources.

Maica offers the capability to automate the generation of timesheet entries records for Resources. This includes dealing with Appointment and Shift timesheet components as well as a number settings that determine how timesheets are managed within Maica.

The generation of timesheets is controlled via a global setting as well as a further setting, called Timesheet Management on an actual Resource record.

Maica's Timesheet Management Process

This diagram represents a workflow related to managing Timesheet Management, particularly in relation to Resources.

  1. Maica generates Timesheet Entries for Resources when either Appointments or Shifts are completed, either manually or via an automated process.

  2. The first check performed by Maica is to determine what Roster Mode the Resource at the time of the Appointment or Shift.

    1. If the Roster Mode is set to Appointment, Maica will generate Timesheet Entries based on all Appointments completed by any given Resource.

    2. If the Roster Mode is set to Shift, Maica will generate Timesheet Entries based on all Shifts completed by any given Resource and ignore any Appointments that might have taken place during a Shift.

  3. The second check is to determine if any Appointment Breaks have been recorded either during an Appointment or a Shift.

    1. If an Appointment Break is marked as Create Corresponding Timesheet, Maica will include the Appointment Break in the Timesheet Entry for any given Resource.

    2. If an Appointment Break is not marked as Create Corresponding Timesheet, Maica will exclude the Appointment Break in the Timesheet Entry for any given Resource.

  4. The third check is to determine if any Travel has been recorded during an Appointment.

    1. If Appointment Travel has been maked as Create a Timesheet Entry, Maica will include the Travel in the Timesheet Entry for any given Resource.

In most cases, Maica will submit all generated timesheet entries to an awards intepretation solution for the purposes of payroll.

Stripe Integration

Learn how to Integrate with Stripe within Maica

How do I integrate with Stripe within Maica?

To learn how to configure the Stripe integration in Maica, please follow the steps detailed below.

1. Assign Stripe API Keys

To begin configuring your Stripe Integration, go to the Maica Settings tab in the Menu bar. When there, select the Payment Management tab to see the following.

There are three fields that are required to be populated, these are:

  • Stripe Publishable Key

  • Stripe Secret Key

  • Stripe Webhook Secret

These keys are taken directly from Stripe, to learn more about Stripes API Keys and how to access them in Stripe, click here.

2. Connect Site (Notifications Endpoint)

Finally, all that is left to do is connect your Site. Select your Site from the dropdown field and click Save to finalise your set up.

To learn more about how to configure aSite in Salesforce and why they are important, click here.

3. Setup Endpoints for Webhooks

Once you have populated the fields above and connected your Site, you need to configure the required Webhooks on Stripe.

You do this by heading to Stripe, searching for Developers and selecting the Webhooks tab.

Once there, select the + Add Endpoint button located in the top right hand corner of your interface.

Here you will prompted by Stripe to add an Endpoint URL and Description. The Description is optional however the Endpoint URL is required.

The Endpoint URL is located in the Payment Management tab of the Maica Settings, as shown below. You can simply copy this directly into Stripe.

After you have populated Stripe with the Endpoint URL, you need to select the Events you want your Endpoint to listen to.

Ensure Events on your account is selected.

Stripe will provide a large list of possible Events, the crucial ones to select for the Stripe Integration with Maica are the:

  • invoice.payment_failed

  • invoice.payment_succeeded

You can find these by simply searching in the Search Events bar at the top of the page. Once done, select Add Events, and then finalise your Endpoint by clicking Add Endpoint.

Price List Entry

Price List Entry records connect your products or services with specific Price Lists. This linkage is essential for defining the price of a product or service within a particular Price List.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Price List Entry object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Price List Entry Schema.

Configuring Maica Components

Learn how to configure key components in Maica

The following articles will show you how to properly setup important components of the Maica system to ensure proper operation. These components are crucial to Maica's lifecycle and enable efficient Service Delivery.

To explore each component in detail and access specific configuration guides, please visit their pages below:

  1. Appointment Services

  2. Support Items

  3. Support Category

Before proceeding with the configuration of the above components, ensure that you understand them in Maica. To learn about each component, please see the following articles:

Shift

The Shift object in Maica represents an available period of work in which Jobs can be scheduled, rostered and delivered.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Shift object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Shift Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Shift Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Shift Start Date Must Be Before Shift End Date

Ensures that the Shift Start Date is before the Shift End Date

Validation Rule Detail

Rule Name

VAL_SHIFT_0001

Error Message

VAL_0001: The Shift Start must be before the Shift End.

Error Location

Shift Start

Error Condition Formula
AND(
    NOT(ISBLANK(maica_cc__Shift_Start__c)),
    NOT(ISBLANK(maica_cc__Shift_End__c)),
    maica_cc__Shift_Start__c > maica_cc__Shift_End__c
)

Permission Sets

Use Permission Sets to manage user access and permissions within Maica.

What is a Permission Set?

A permission set is a collection of settings and permissions that give users access to various tools and functions. Permission sets extend users’ functional access without changing their profiles and are the recommended way to manage your users’ permissions.

How is Permission Managed in Maica?

Maica leverages standard Salesforce to provide access to its range of features.

For example, let’s say you have several staff members who need the ability to enter Invoices and Claim funds from the NDIS. Assign these users the Maica - Manage Plan & Service Booking Permission Set to ensure they can access the features and functionality required in this process.

Taking this a step further, assume that only 1 of these staff members needs the ability to delete a Service Booking. Assign this user the Maica - Delete Service Booking Permission Set in addition to the one above to enable this additional functionality.

The Permission Set is complementary to their Profile, meaning it provides access to these Maica features in addition to what is already provided via their existing Profile

Maica Permission Sets

The table below provides an overview of the standard Maica Permission Sets and an example of the intended user.

Permission Set Name
Who is this for?

Full Permission Set Overview

You can access a full overview of all the Maica Permission Sets in the Google Sheet below.

Click to view and download the complete Maica Permission Matrix.

Data Import Utility

Learn how to Import Data into Maica

What is the Data Import Utility?

The Data Import Utility in Maica is a tool that allows you to quickly and easily import data into Maica. There are a number of important Data Records that must be up to date and are critical to keeping Maica functioning effectively, including Support Catalogues and Price Lists, and hence importing Data efficiently is of upmost importance. The Data Import Utility allows you to stay on top of these updates without having to ever manually compare new Catalogues or Lists with your current Data.

Where do I find the Data Import Utility?

In order to access the Data Import tool, first click the App Launcher located in the top left corner of your interface, as shown below.

Once open, simply search Data Import and select the Data Import tool under Items, as shown below.

In order to see the Data Import tab - you need to have the Maica - Manage Maica Settings assigned to your user.

How do I use the Data Import Utility?

1. Select Flow Setting

After you have opened the Data Import Tool, you will be presented with the following screen:

As the utility supports a few different processes, the first step is to select the Flow Setting or Import Process. Maica supports the following options:

  • Reference Data Import

  • NDIS Bulk Payment Request Results File

  • NDIS Import Support Items Catalogue

  • NDIS Bulk Payment Remittance File

This Flow Setting essentially tells Maica which type of Data you are wanting to Import so the Automation can read the files correctly.

2. Import File

Once you have selected the required Flow Setting, the page will dynamically update and present you with a Upload Files button. Simply click this button and select the desired file.

Files used by the Data Import Utility must have a CSV file format.

3. Confirm Import

After uploading your File, you will see the following two options displayed:

  • Check Only: Check this option if you want to validate the file and the import prior to processing it. By selecting Check Only, no records will be created or updated in Maica.

  • Allow Parallel: Check this option if you want to create multiple records simultaneously to process the file quicker. If you require your records to match the order of the file, ensure this checkbox is not selected.

Once done, click Import to confirm.

If you are Importing NDIS Import Support Items Catalogue, there are a few additional steps. Click to learn more.

Price List

The Price List object in Maica manages pricing information for your products or services.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Price List object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Price List Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Price List Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Price List End Date Cannot Be Before Start Date

This rule ensures that the Price List End Date is not before the Start Date.

Validation Rule Detail

Price List Start Date Cannot Be After End Date

This rule ensures that the Price List Start Date is not after the End Date.

Validation Rule Detail

Enable Maica Actions

Learn how to add Maica Actions to your Salesforce Global Actions menu.

The following article describes the process of adding Maica Actions to your Salesforce Global Actions menu.


How to Add Maica Actions to the Salesforce Global Actions menu

Step 1: Access the Setup Menu

  1. Click on the Setup icon in the top-right corner of Salesforce.

  2. In the Quick Find search bar, type Global Actions or Publisher Layouts.

Step 2: Navigate to Publisher Layouts

  1. In the left-hand menu, expand User Interface > Global Actions.

  2. Click on Publisher Layouts.

Step 3: Edit the Global Publisher Layout

  1. Locate the Global Publisher Layouts section.

  2. Click Edit next to the existing layout you want to modify.

Step 4: Access Mobile & Lightning Actions

  1. In the layout editor, find the Global Layout panel.

  2. Click on Mobile & Lightning Actions to display the Maica Actions.

Step 5: Add Maica Actions

  1. In the Quick Find bar, identify the Maica Actions.

  2. Drag and drop Maica Actions into the Salesforce Mobile and Lightning Experience Actions section.

We recommend dragging the Maica Actions to the front of the action list for better visibility. This ensures it appears at the top of your Global Actions menu.

Step 6: Save Changes

  1. Click Save in the layout editor to apply your customisation.

Step 7: Refresh and Verify

  1. Refresh your Salesforce browser window.

  2. Click on the Global Actions dropdown in the top-right corner.

  3. Confirm that Maica Actions now appears at the top of the menu.


Check out the guide below to watch each step in real time.

Support Item Management

Learn about Support Item Management Settings in Maica

The Bulk Price List Update section allows you to apply a selected Price List to Service Agreements in bulk. You can choose to:

  1. Apply a Price List Immediately — this updates all currently Active Service Agreements right away.

  2. Schedule a Price List Update — this sets a future date on which the selected Price List will take effect.

Please note, you can define which Service Agreements should be impacted by the Price List update by adding filter criteria. By default, only Agreements with a Status of “Active” will be updated. However, you can optionally add additional fields to target specific subsets of Agreements.

Please refer to the below table for more information on each setting:

Setting
Description

Stripe Integration

Learn about Stripe Integration Settings in Maica

The Stripe tab in the Integration Management screen allows Maica administrators to configure the Stripe payment gateway.

Please see the breakdown below for further information on each section:

1. Stripe API Keys

To connect your Stripe account with Maica, you’ll need to enter three API credentials:

  • Stripe Publishable Key

  • Stripe Secret Key

  • Stripe Webhook Secret

These credentials can be generated within your Stripe account and must be pasted into the fields provided in Maica.

For detailed instructions on where to find these keys and how to configure your Stripe account, refer to the full .

2. Site Configuration

In order for the Integration to function properly, a Site must be selected from the list.

Please note, this Site must be configured to serve the public-facing payment page, and the associated Site User must have appropriate access in order to enable the Pay Now link for the Invoice PDF.

Use the search field to locate and select the correct Site record.

For more information on how to set up and configure Sites in Maica, see .

Integration Management

Learn about Integration Settings in Maica

These settings determine how Maica manages all of their Integrations and their function throughout the application.

To dive deeper into each of the Integration's Settings, please visit their specific pages linked below:

General Settings

Learn about General Connections Management Settings in Maica

These settings determine how gender is interpreted within Maica when generating reciprocal Connections.

Please refer to the below table for more information on each setting:

Setting
Description

Any values not added to the Male or Female columns will automatically be treated as Neutral. Neutral values will generate reciprocal Connections based on the "Neutral" column in the Reciprocal Settings.

Rostering Management

Learn about Rostering Management Settings in Maica

Rostering is an important part of the scheduling and resource management process which focuses on allocating the most appropriate resources (care workers) to Appointments. Maica offers a number of Settings on how this allocation is managed, as shown in the table below.

These settings determine how Maica manages Rosters and their function throughout the application. Please refer to the below table for more information on each setting:

The below settings can be configured independently for both Appointments and Shifts. Values defined under each tab will apply only to that respective type.

Setting
Description

Timesheet Management

Learn about Timesheet Management Settings in Maica

These settings determine how Maica manages Timesheets and their function throughout the application. Please refer to the below table for more information on each setting:

Setting
Description

Timesheet Entry Text Format

Please refer to the below table for more information on each setting:

Setting
Description

Appearance Settings

Please refer to the below table for more information on each setting:

Setting
Description

Xero Integration

Learn about Xero Integration Settings in Maica

This section of Maica allows administrators to manage and configure their Xero integration.

Please see the breakdown below for further information on each section:

1. Enable the Integration

Ensure the Xero Integration toggle at the top of the settings page is switched to Enabled. This is required to activate any of the settings or integrations below. If this toggle is off, Maica will not attempt to communicate with Xero, and synchronisation will not occur.

2. Active Connections

Active Connections display which Xero organisations Maica is currently linked to. If multiple companies exist in your Xero instance (e.g. a Production and Demo organisation), Maica will list them here and allow you to select the one to connect with.

For more information on connecting Maica to Xero and setting up your Connection, please .

3. Webhooks

This section configures the Site Maica will use to listen for real-time Xero Notifications.

For more information on setting up Webhooks in Maica, please .

4. Synchronisation

This section controls how invoices are synchronised between Maica and Xero.

  • Invoice Xero Sync Flow: Select the Automation flow responsible for pushing invoices to Xero.

  • Run Now: Click this button to manually trigger the Invoice Synchronisation.

Once configured, Maica will regularly run the selected flow to keep Xero updated with Maica invoice records.

Invoice Management

Learn about Invoice Management Settings in Maica

Please note, The Subsidy Invoices and Out-of-Pocket Invoices sections share the same Invoice Management Settings. To avoid repetition, the settings are explained once below. Each setting functions the same way in both sections but can be configured independently depending on your invoicing needs.

These Settings determine how Maica manages Invoices and their function throughout the application. Please refer to the below table for more information on each setting:

Setting
Description

Apply this Price List

Select the Price List you want to apply to existing Service Agreements. This field is used for an immediate update.

Confirm Toggle

A toggle that confirms your intention to perform the immediate update. Once confirmed, the Update Price List button is activated.

Price List (Scheduled)

Select the Price List that should take effect on a future date.

Effective Date

Defines when the selected Price List should be applied. No changes occur until this date is reached.

Enable

Applies the scheduled update. Once enabled, Maica will automatically update all qualifying Service Agreements on the selected date.

Gender Field

Specifies which field in your Salesforce org represents a Contact’s gender. Maica uses this field to determine the appropriate reciprocal Connection.

For example, if you create a Connection from a "Mother" Contact and the selected Contact is Female, Maica will generate a reciprocal Connection of "Daughter" (instead of "Son").

Male Values

Define which values from the selected Gender Field should be interpreted as Male.

To assign a value to Male, select it from the Available list and click the right arrow to move it to the Selected list.

Female Values

Define which values from the selected Gender Field should be interpreted as Female. To assign a value to Female, select it from the Available list and click the right arrow to move it to the Selected list.

Enable Timesheet Generation

This enables Maica to generate timesheets when either Appointments or Shifts are completed. This setting works in conjunction with the Enable Timesheets attribute on the Resource profile.

Timesheet Entry Reference

This determines which date from the Appointment or Shift will be used when Timesheet Entries are being generated.

Text Format

The Maica Timesheet Management console allows you to specify what text appears in the cells of Timesheet Entries.

This settings defines this by using a formula-based approach in which you can configure exactly what you want the text to be. This includes the merging of record attributes as well as your own text.

Non-billable Colour

This determines the cell colour of any non-billable Timesheet Entries, in other words, Timesheet Entries not associated with an Appointment or Shift.

Billable Colour

This determines the cell colour of any billable Timesheet Entries, in other words, Timesheet Entries associated with an Appointment or Shift.

Appointment Colour

In cases where the Timesheet Generation is disabled, the Maica Timesheet Management console shows all completed Appointments or Shifts which can then manually converted to a Timesheet Entry. This setting determines which colour will be used when showing either Appointments or Shifts in the Maica Timesheet Management console.

Appointment Break Indicator Colour

The Maica Timesheet Management console shows Appointment/Shift breaks and this setting determines what colour will be used when displayed.

Travel Colour

The Maica Timesheet Management console shows Travel (associated with an Appointment or Shift) and this setting determines what colour will be used when displayed.

Invoice Period

Defines how often Invoices are grouped and generated in Maica (e.g. weekly, fortnightly, monthly). This determines the Invoice cycle used when calculating Invoice batches.

Invoice Period Anchor Date

Specifies the starting reference point for calculating Invoice periods. This date works in combination with the selected Invoice Period to determine how invoice batches are grouped.

For example, if the Invoice Period is set to “Weekly” and the Anchor Date is 1st January, Maica will generate invoice batches from 1st–7th January, 8th–14th January, and so on.

Payment Terms (days)

Sets the expected number of days in which payment is due after an invoice is issued. It is used to set the Due Date on the created Invoice records.

Paid Tolerance

Specifies an allowed variance between the claimed amount and the paid amount before the invoice is flagged. For example, a tolerance of 0.1 allows for small rounding or pricing discrepancies without requiring manual intervention. Note: This only applies to NDIS Claimed Agency Managed Invoices

Stripe Integration article
Create a Site
NDIS Integration
Stripe Integration
Xero Integration
click here
click here
Permission Set
here

The Maica Release Process

Learn about Maica's Software Release and Upgrade Process

All Maica releases are published on our website here. It is our aim to release new versions of Maica every quarter depending on complexity of new features and other factors that may impact on this timeline.

The Maica Release Process

When Maica issues a new solution version, a number of artefacts will be published alongside any release, including the following:

Interactive Feature videos

We showcase most of Maica's features on our website through a number of interactive videos that allow you to experience Maica with ease. When a new release is about to be published, we will add any relevant feature videos to this site so please visit to find out what's new.

Knowledge Base articles

Our Knowledge Base is the main tool for you to understand how Maica works, both from an end-user and administration perspective. We will update any relevant articles or add new ones to reflect all new features or improvements in Maica to make sure you have access to the latest information on how it works.

Release Notes

Release Notes are an essential part of any Maica release and we will publish these on our website as a page and downloadable PDF. This will include all required post-installation steps and scripts in case you want to upgrade Maica yourself.

LinkedIn Post

We have a Maica LinkedIn profile on which we publish almost daily, so please check in for the latest information, updates, and release information. We will post all new releases here for your ease of access.

Broadcast Email

If you are a current Maica client, you will be on our broadcast list so you will receive a special type of broadcast to announce a new release. This will then also includes links to all of the above for your convenience. Look out for these!

The Maica Upgrade Process

The Maica software release and upgrade process is outlined below to ensure clarity across the various tasks and responsibilites that take place during this timeline.

  1. Maica will release a package to its clients only if all of the below have been tested and published:

    1. Software Package

      1. the technical package which will be installed using a URL

    2. Release Notes

      1. these can be found here for reference and will contain a detailed description of all features/bugs fixes/etc introduced as part of any given release

    3. Post-Installation Steps

      1. these are usually steps that need to be taken to configure any additional elements that the automated installation process does not address

It is important to note that the above will only ever be applicable to the core package. In other words, these steps will ensure compatibility with the native Maica package only and any client-specific customisations will be looked at as part of the next stages of the upgrade process.

The next stages look at client-specific customisation that might have been configured by an implementation partner to ensure compatibility with these unique structures. This will involve the following steps/tasks:

  1. The implementation partner will investigate and determine any client-specific post-installation steps or scripts that need to be run. This might involved additional development work to ensure compatibility going forward.

  2. The client is then asked to complete the Maica Upgrade Agreement in which we seek proof that all relevant testing was completed in a reppresentative sandbox to ensure the upgrade will be successful.

  3. Once this has been completed (via DocuSign), the relevant team members from the implementation partner and the client are allocated to the Maica upgrade project with the following artefacts to be part of the upgrade:

    1. Upgrade Timeline

    2. Upgrade Team Members

    3. Client-specific technical scripts (to be run in the client's Salesforce production instance)

    4. Acceptance Certificate to be issued following the upgrade project completion.

Once an upgrade is completed, Maica takes responsibility for any resulting application defects and will address these as the highest priority but will not be responsible for any resulting data integrity issues nor any customisations not implemented directly by the implementation partner that might impact the performance of Maica in the client’s environment.

Renewal Management

Learn about Renewal Management Settings in Maica

Maica gives you the ability to automatically generate new Service Agreement records ahead of expiry, helping you stay proactive with renewals. These settings allow you to define when and how a Renewal Service Agreement is created, and who it is assigned to.

The configuration options below apply to Service Agreements with an End Date, and each setting plays a role in determining how the new Agreement will be generated when the renewal logic runs daily.

Please refer to the below table for more information on each setting, and the section below for more detail around the entry criteria (the criteria required for a Service Agreement to be included in the automated renewal process):

Setting
Description
Configuration Options

Renew Service Agreements

Defines how many days before the current Service Agreement ends that the system should trigger the renewal logic. This is when the new Service Agreement record will be created.

Numeric (1-100)

Set the Renewal Service Agreement Start Date to

Sets the start date of the new Agreement relative to the current Agreement's End Date. For example, entering '1' means the new Agreement will begin the day after the existing one ends.

Numeric (1-100)

Set the Renewal Service Agreement End Date to

Sets the duration of the new Agreement by specifying how many days it should run for from the new Start Date.

Numeric (1-100)

Assign the Renewal Service Agreement to

Choose whether the new Agreement should be assigned to the current owner of the expiring Agreement or a specific user.

Select

Daily Service Agreement Renewal Time

Defines the time each day that Maica will run the automated renewal logic. Only Agreements within the configured date window will be actioned.

Time Picker

Run Now

Immediately runs the renewal logic using the settings above.

Entry Criteria

For a Service Agreement to be included in the automated renewal process, it must meet the following criteria:

  • Auto Renewal is enabled on the record (Auto_Renewal__c = TRUE).

  • End Date of the Service Agreement falls within the configured renewal window.

The renewal window is determined using this logic: The system checks if the Agreement’s End Date is within X days from today, where X is the number configured in Renew Service Agreements.

For example, if Renew Service Agreements is set to 30, the system will begin considering Agreements for renewal when their End Date is within 30 days from the current date.

Agreements that meet both conditions will be processed when the daily renewal job runs.

Maica - General User

This needs to be assigned to all of your Maica users.

Maica Client Care - Care Worker

This needs to be assigned to all your care workers who work in service delivery

Maica Client Care - Manage Service Delivery

This set is designed for users who oversee service delivery processes. It includes permissions to create, update, and view critical service-related objects.

Maica - Manage Maica Settings

This set allows users to view and modify Maica system settings. It is intended for system administrators or managers who need to adjust configurations and settings within Maica for system-wide operations.

Maica - Manage Crediting

This set is for users involved in the financial side of Maica, particularly around invoicing and crediting. It provides the ability to manage credits and is linked with invoicing and claiming permissions to ensure proper financial adjustments and management.

Maica - Delete Service Booking

This set is assigned to users who have the authority to delete service bookings. It grants specific permissions for managing service bookings, ensuring that they can remove bookings when necessary, typically handled by administrative staff.

Maica - Process Stripe Payments

This set is intended for users who handle payments through Stripe. It provides permissions to process and view payments.

Maica - Manage Invoice & Claiming

This should be assigned to users responsible for managing invoicing and claim submission processes, including generating and submitting invoices for services provided.

Maica - Manage Plan & Service Booking

This set is for users who manage participant plans and service bookings. It includes permissions to create, update, and manage Plan Budgets and Plan Goals, ensuring that participant services are properly aligned with their NDIS plans.

Permission Sets
here

Rule Name

VAL_PRICE_LIST_0001

Error Message

VAL_0001: The End Date cannot be before the Start Date.

Error Location

End Date

Error Condition Formula
AND(
    NOT(ISBLANK(maica_cc__End_Date__c)),
    maica_cc__End_Date__c < maica_cc__Start_Date__c
)

Rule Name

VAL_PRICE_LIST_0002

Error Message

VAL_0002: The Start Date cannot be after the End Date.

Error Location

Start Date

Error Condition Formula
AND(
    NOT(ISBLANK(maica_cc__Start_Date__c)),
    maica_cc__Start_Date__c > maica_cc__End_Date__c
)
here

Matching Score Importance Level

As Maica calculates the overall matching score for Resources, it is possible for you to assign an importance level to each criteria used in this calculation. This means, you are able to set what is more important when finding and allocating resources; for example, if assigning a higher percentage to Skills, then the algorithm will attribute a higher percentage to the matching of Skills in preference of another dimension

Default Unavailability Status

When resources create Unavailability records (pending permissions), this Settings determines what Status will be used when this record is created. This essentially allows you to build any relevant approval process around unavailability as per your organisational requirements.

Default Unavailability Schedule Status

Sets the Status applied to the Schedule linked to an Unavailability record. This status is used when a Schedule is created or updated (e.g. when marking an Unavailability as recurring).

Default Appointment Break Status

When resources create (pending permissions), this Settings determines what Status will be used when this record is created.

Daily Recurring Unavailability Creation Time

Specifies the time each day that Maica runs a batch process to create Recurring Unavailability records, based on active Unavailability Schedules. This operates similarly to Recurring Appointments.

Payment Request

This object in Maica represents the details of a Payment Request claimed from the NDIA - for Clients with an Agency Managed Service Agreement.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Payment Request object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Payment Request Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Payment Request Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Status Cannot Be Changed When Payment Request Status is Paid

When the Payment Request Status is updated to Paid, the Status on the record cannot be changed.

Validation Rule Detail

Rule Name

x01_Paid_PR_Cannot_Be_Changed

Error Message

You cannot modify a Paid Payment Request. Payment Request Error x01.

Error Location

Top of Page

Error Condition Formula
AND(
ISPICKVAL(PRIORVALUE(maica_cc__Status__c), "41"),
NOT(ISPICKVAL(maica_cc__Status__c, "41"))
)

Automation

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Payment Request Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Payment Request Initialise Claim Reference

This trigger is designed to initialise the claim reference for payment requests in Maica.

Detail

Load Order

1

Label

PaymentRequestInitClaimReference_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the PaymentRequestInitClaimReference_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the initialization of the claim reference for payment requests.

  • Trigger Conditions:

    • When a new payment request (maica__Payment_Request__c) is created.

    • When an existing payment request is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a payment request record is created or updated, the trigger is initialised. The PaymentRequestInitClaimReference_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the PaymentRequestInitClaimReference_MDTM class.

    • The class methods perform the following steps:

      • Validation: The payment request data is validated to ensure it is complete and accurate.

      • Initialisation: Based on predefined criteria, the claim reference is initialised to ensure each payment request has a unique and consistent reference.

      • Update: The payment request record is updated with the newly initialised claim reference.

Trigger Outcome:

Once executed, the trigger ensures that each payment request has its claim reference initialised correctly, according to the logic specified in the handler class. This helps maintain accurate and consistent claim reference data for payment requests.

Funding Item

This object in Maica represents the specific Budget Items or Funded Supports included in a Participant's NDIS Funding or Home Care Package.

Depending on your Maica package, this Data Object may be called Plan Budget in your organisation

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Funding Item object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Funding Item Schema.

Automation

Flows

The list below outlines the Flows applied to the Funding Item Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Update Is Active Value

This flow is designed to update the Is Active field value for a Funding Item record based on its Effective Date and End Date.

Flow Detail

Flow Label

Maica - Funding Item - Update Is Active Value

API Name

maica__Maica_Funding_Item_Update_Is_Active_Value

Type

Autolaunched Flow

Flow Summary

  • Updates the Is Active field for a Funding Item record based on its Effective Date and End Date.

  • Ensures the Is Active field reflects the current status of the Funding Item according to the specified dates.

Flow Description
  1. Start (Record-Triggered Flow):

    • Triggered when the Effective Date, End Date, or Is Active field is changed.

  2. Calculate Is Active Status (Formula):

    • Determines if the Funding Item is currently active based on the Effective Date, End Date, and current date.

  3. Update Funding Item Record (Record Update):

    • Updates the Is Active field with the calculated status.

Funding Item Before Insert

This flow is designed to set attribute values from the related Product before inserting a Funding Item record.

Flow Summary

  • This flow sets the attribute values for a Funding Item record from the related Product before the record is inserted or updated.

  • It ensures that the Funding Item's Unit of Measurement and Support Purpose Picklist fields are accurately populated.

Flow Description
  1. Start (Record-Triggered Flow):

    • Triggered before inserting or updating a Funding Item record.

  2. Calculate Unit of Measurement (Formula):

    • Converts the Unit of Measurement from the related Product record to text.

  3. Assign Plan Budget Values (Assignment):

    • Sets the Product Unit of Measurement and Support Purpose Picklist fields on the Funding Item record based on values from the related Product.

Create a New Participant Note Template

This article provides a walkthrough of creating a new Participant Note Template in Maica

To utilise Participant Note Templates in Maica, please follow the steps outlined below.


1. Search for Participant Note Templates in the App Launcher

In the Salesforce App Launcher, search for Participant Note Templates.

Click into the Participant Note Templates tab to create a new template.


2. Create a New Template

Once there, click New to begin setting up a new template. You’ll be asked to fill out a few key details:

  • Name: Give your template a clear and descriptive name.

  • Description (optional): Add context about when or why this template is used.

  • Category: Choose a category to help organise your templates.

The Category sets the category of the Participant Note when created using a Template.

  • Template Content: Enter the note content that will appear when the template is selected


3. Set the Template Visibility

You can choose whether the template should be:

  • Public – Available to all users

  • Private – Available only to you

Once configured, click Save.

You can also choose whether the template should be Active or not. Inactive templates will not appear as selectable options.


4. Using the Template During an Appointment

Once saved, the new template becomes selectable when logging participant notes:

  1. Open the Planner and begin logging a new participant note.

  2. Select a note template from the list (e.g., Demo Note).

  3. Click Confirm to apply the template content to the note.

  4. The text from the template will be pre-filled and ready to complete.

Interactive Demonstration

The interactive demonstration below showcase the process outlined above.

The video covers each step in the creation of a Participant Note Template workflow.

Participant Notes

Learn about Participant Note Settings in Maica

These settings determine how Maica manages Participant Notes and their function throughout the application. Please refer to the below table for more information on each setting:

Setting
Description

Default Category

This determines the default to be assigned to any new Participant Note that is created.

Default Interaction Type

This determines the default to be assigned to any new Participant Note that is created.

Default Appointment Service

Participant Notes can be billed like , for use cases such as report writing or support coordination. In order to enable this billing to take place, an Appointment Service must be selected when capturing the Participant Note. This setting determines which default Appointment Service will be assigned to any new Participant Note that is created, meaning the user does not have to manually select it.

Available Appointment Services

In addition to being able to set a default Appointment Service, this setting records a list of any Appointment Service that can be selected for a Participant Note in cases where the user wants to change the default service.

Default Duration (minutes)

This sets the default in minutes for any new Participant Note that is created.

Custom Fields

Similar to , it is possible to include custom fields when capturing Participant Notes. This settings determines which fields (both native or custom-configured) are presented to the user when creating a Participant Note. Participant Notes custom fields appear on the second step when creating notes. Click Next & Save to access this part of the process.

Default Claim Type

This sets the default for any new Participant Note that is created; this will directly impact on the generates for billing the time for capturing the Participant Note.

Service Agreement Statement

This object represents a financial summary statement of a Service Agreement during the defined claim period. Referenced for claim extracts and monthly client statements.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Service Agreement Statement object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Service Agreement Statement Schema.

Automation

Flows

The list below outlines the Flows applied to the Service Agreement Leave Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Recalculate Service Agreement Statement Screen Flow

This guided flow facilitates the recalculation of an existing Service Agreement Statement record.

Flow Detail

Flow Summary

This flow guides the user through recalculating an existing Service Agreement Statement record:

  • Starts from a user-initiated screen flow.

  • Retrieves the Service Agreement Statement record.

  • Calls a subflow to perform the recalculation.

  • Checks for any fault messages and displays appropriate success or error messages based on the recalculation outcome.

Flow Description
  1. Start (Screen Flow):

    • The flow begins when a user starts the flow from the screen.

    • It guides the user to initiate the recalculation process.

  2. Recalculate Service Agreement Statement (Screen):

    • Displays instructions to the user about the recalculation process.

    • User clicks "Next" to proceed.

  3. GET Service Agreement Statement (Record Lookup):

    • Retrieves the Service Agreement Statement record using the provided record ID.

    • Passes the retrieved record to the subflow for recalculation.

  4. Call Generate Service Agreement Statement Flow (Subflow):

    • Calls the "Maica_Generate_Service_Agreement_Statements" subflow to perform the recalculation.

    • Inputs provided to the subflow:

      • Claim_Period_End_Date: End date of the statement period.

      • Claim_Period_Start_Date: Start date of the statement period.

      • Recalculate_Statement: Set to true to trigger recalculation.

      • Service_Agreement_Id: ID of the associated Service Agreement.

      • Service_Agreement_Statement_Id: ID of the Service Agreement Statement to be recalculated.

    • Outputs:

      • FlowFaultMessage: Captures any fault messages during recalculation.

  5. DECISION Flow Fault Message Set (Decision):

    • Checks if there is any fault message after the recalculation:

      • If a fault message is set, the flow proceeds to show the "Recalculation Failed" screen.

      • If no fault message, the flow proceeds to show the "Recalculation Complete" screen.

  6. Recalculation Complete (Screen):

    • Displays a success message indicating that the Service Agreement Statement has been successfully recalculated.

  7. Recalculation Failed (Screen):

    • Displays an error message with the fault details if the recalculation fails.

    • Advises the user to contact the system administrator and provide the fault message.

Resource Participant

The Resource Participant object in Maica captures the Participants a particular Resource looks after.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Resource Participant object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Resource Participant Schema.

Automation

Flows

The list below outlines the Flows applied to the Resource Participant Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Resource Participant Trigger

This flow updates the Resource Participant record based on its Start Date and End Date.

Flow Detail

Flow Summary

This flow ensures that the Resource Participant record is updated based on its Start Date and End Date.

  • Starts on Resource Participant record creation or update.

  • Updates the record on the Start Date.

  • Updates the record 1 day after the End Date.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow begins when a Resource Participant record is created or updated.

    • It is triggered after the record is saved.

  2. Update Record (Scheduled Path - Start):

    • Updates the record based on the Start Date.

    • This path is scheduled to run immediately (0 days) after the Start Date.

  3. Update Record (Scheduled Path - End):

    • Updates the record based on the End Date.

    • This path is scheduled to run 1 day after the End Date.

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Service Agreement Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Resource Participant Manual Share

This trigger is designed to manage the manual sharing of resource participants in Maica.

Detail
Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the ResourceParticipantManualShare_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the manual sharing process for resource participants.

  • Trigger Conditions:

    • When a new resource participant (maica__Resource_Participant__c) is created.

    • When an existing resource participant is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a resource participant record is created or updated, the trigger is initialised. The ResourceParticipantManualShare_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ResourceParticipantManualShare_MDTM class.

    • The class methods perform the following steps:

      • Validation: The resource participant data is validated to ensure it is complete and accurate.

      • Manual Sharing: Based on predefined criteria, manual sharing is executed to ensure each resource participant is shared appropriately.

      • Update: The resource participant record is updated with the newly shared details.

Trigger Outcome:

Once executed, the trigger ensures that each resource participant is shared manually as required, according to the logic specified in the handler class. This helps maintain accurate sharing details for resource participants.

The Implementation Process

Learn about what an implementation of Maica looks like.

Maica is a purpose-built healthcare application for Australian NDIS and Aged Care providers and does not require any implementation to get started. We have described below the various steps involved in not only getting started with Maica but also extend it over time to grow alongside your organisation.

Maica is built on the digital client management system and, as such, there are several models under which you can purchase the underlying Salesforce platform, as shown below:

  • OEM - this means that when purchasing Maica directly from us, this will include the underlying Salesforce platform (Salesforce Platform Starter Edition) so there is nothing else for you to do to get started.

  • ISV - this means that you are purchasing Salesforce directly from Salesforce, via an Account Executive most likely, which then allows us to install Maica into your Salesforce environment.

  • Mixed- this means that you may already have a Salesforce environment and want to expand this using Maica. In this case, we are able to provision OEM licences to your organisation or install Maica under the ISVmodel.

All underlying Salesforce instances must be hosted in Australia to be compliant with the NDIS and Aged Care legislation. When purchasing under ISV, please ask your Salesforce Account Executive to ensure this is the case. Maica will natively be hosted in Australia when purchssed under the OEMmodel.

The Maica Standup Process (Mandatory)

As part of your licence subscription, we will provide the following standup services free of charge to you to.

At the conclusion of this stage of your Maica adoption, we will ask you to formally accept the core Maica product prior to potentially extending your specific solution to meet particular organisational needs.

Task
Description
Assumption

Everything documented in the Maica Knowledge Base is part of the core solution and requires no implementation fees whereas anything not documented in the Maica Knowledge Base is considered an extension and will go through our .

The Maica Extensions Implementation Process (Optional)

In cases where your organisation has implementation needs beyond the core Maica product (as documented in the Maica Knowledge Base), Maica follows a strict Time & Materials approach whilst working with your team to define, determine, and implement the most appropriate technical solution(s) to meet your needs. This commercial model also keeps you in charge of how much financial input an implementation might require.

The below table outlines some of the more typical tasks we have come across for your reference:

Task
Description

How to get started?

The best way to get started with Maica would be to from us, or simply to speak to our team.

Appointment Services

Learn how to configure Appointment Services in Maica

How do I configure Appointment Services?

To correctly configure an Appointment Service, please follow the steps indicated below.

1. Search for Appointment Services in the App Launcher

In the Salesforce App Launcher, search for Appointment Services and choose it to open the list view of all Appointment Services in your Maica instance, as shown below.

The Salesforce App Launcher is found in the top left corner of your interface.

2. Create new Appointment Service

Once you are viewing your Appointment Services, simply click the New button located in the top right hand corner of your interface to bring up the New Appointment Service pop-up, as shown below.

After the pop-up is displayed, you will be prompted to fill-in the following fields:

Field
Description

Finally, once populated, simply click Save to create your Appointment Service.

3. Assign relevant Skills and Checklists

Select your newly created Appointment Service to open up the record. Once open, you will see the related list fields on the right hand side of your interface, as shown below.

This step is only going to focus on Skills and Checklists. Both of these related lists work the same way, which is:

  1. Click the New button to add Skills and Checklists

  2. Select which Appointment Service you wish to assign the Skill or Checklist too. The Service you open the selector from will be selected by default.

  3. Select which Skill or Checklist you wish to assign, and set its associated Requirement Level to either Required or Recommended.

  4. Click Save to finalise your selection.

Note, you can also assign Skills and Checklists to an Appointment Service through the related lists on the relevant Skills and Checklists records.

4. Assign Support Items to an Appointment Service

Note, you must have configured your Support Items before assigning them an Appointment Service. In order to learn how to configure Support Items, click .

Please note that depending on the version of Maica you are using, Support Items may be referred to as Products (the NDIS term) in your instance.

Again, on your newly created Appointment Service, refer to the related list fields on the right hand side of your interface to identify the Support Items list. Here you will see all associated Support Items within an Appointment Service.

It is crucial to note here that assigning Support Items does not work in the same way as assigning Skills and Checklists. Clicking the New on the Support Item related list directly from your Appointment Service record will create an entirely new Support Item, not assign an existing one. In order to assign a Support Item to an Appointment Service, you must do it directly from the Support Item record.

As mentioned, in order to assign a Support Item to an Appointment Service, you must do it directly from the Support Item record. This is due to the fact that one Support Item can only ever belong to one Appointment Service.

To explain how this process works, please refer to the demonstration below. In the Demonstration, the following examples will be used and referenced:

  • Appointment Service: Recovery Coaching

  • Support Item: Psychosocial Recovery Coaching - Saturday

Now, your Appointment Service is ready to be used.

Things to look out for: Basic Details

1. Duplicate Support Items

When configuring Appointment Services, it is crucial that no Support Items with the same configuration are assigned to the same Appointment Service, as this will disrupt Maica's ability to accurately validate the Participants funding, and potentially disrupt the .

If two Support Items (with identical configurations) were to be assigned to the same Appointment Service, the Billing Automation would face ambiguity. Maica’s Billing Automation relies on identifying a unique Support Item within an Appointment Service to bill correctly. If multiple Support Items with identical identifiers were present, the Automation wouldn’t know which one to bill against, potentially leading to billing errors or incorrect Invoicing. To learn more about the Billing Flow, click .

The following four fields in a Support Item decide whether they are considered 'identical' within the Maica system:

  1. Service Day

  2. Service Time

  3. Support Category

  4. Registration Group

So, in summary, no two Support Items with identical inputs to the four fields listed above can exist within the same Appointment Service. If one field differs, they can exist.

Please note, Maica's SupportItemServiceValidation_MDTM trigger based Automation will prevent this from occurring given this trigger is enabled.

Reciprocal Settings

Learn about Reciprocal Connections Management Settings in Maica

This section allows you to define how Reciprocal Connections should behave. When a user creates a Connection on a Contact, Maica will reference this table to determine what the reciprocal Connection should be—depending on whether the Contact's gender is identified as Male, Female, or Neutral.

Each row represents a type of Connection and how it is reciprocated based on gender.

Please refer to the below table for more information on each column in the Reciprocal Settings, and the information below to learn how to create a new Reciprocal Setting:

Setting
Description

How to Add a New Reciprocal Setting

To add a new Connection type:

  1. Scroll to the bottom of the Reciprocal Settings table.

  2. Click the + Add Reciprocal Setting button.

  3. In the new row that appears:

    • Enter a name in the Name column (e.g. "Uncle").

    • Specify the Male, Female, and Neutral reciprocal terms (e.g. "Nephew", "Niece", "Sibling's Child").

  4. Ensure the Active checkbox is ticked if you want this setting to be used by Maica.

  5. Click outside the input fields to save the new row automatically.

Note, you can also edit any existing reciprocal setting by clicking into the text fields directly. Use the trash can icon on the right to remove a row if needed.

Example: How Maica Creates Reciprocal Connections

The following example illustrates how Maica automatically creates a reciprocal connection based on the configured settings:

Let's say a record is created for a Contact named Bryce. The Related Contact selected is Emma, and the Type selected is Son.

Note, this record is created from the Related List on the Contact profile

When the record is saved, Maica uses the Reciprocal Settings and Gender Field mappings to determine the appropriate reciprocal relationship.

  • The reciprocal value for Son, as configured in the Reciprocal Settings, could be:

    • Father if the Related Contact is Male

    • Mother if the Related Contact is Female

    • Parent if the Related Contact is Neutral or has no specified gender

Since Emma has a Gender field value of Woman, and "Woman" is mapped to the Female category in the Gender Settings, Maica creates a reciprocal Connection where:

  • The Contact is Emma

  • The Related Contact is Bryce

  • The Type is set to Mother

If Emma's gender had not been defined or was not mapped to either Male or Female, the reciprocal Connection would have used the Neutral value, resulting in a Type of Parent.

Support Categories

Learn how to configure Support Categories in Maica

Please note that that NDIS Support Categories will be configured into your Maica instance by the Maica team during Post Installation. The following article is only about configuring custom Support Categories for Home Care Packages.

When it comes to Home Care Packages, custom fields have been added to the Support Category object in Maica. These allow you to configure appropriate Support Categories to represent the Home Care Package Budget, and allow our feature to interrogate the Support Category Records in your system to ensure that you can effectively set up and manage budgets while adhering to Home Care Package requirements.

Support Categories Template

As well as the ability to configure Support Categories, Maica offers a template with default categories, categorised by the various line items that form a package budget for home care, as per the table below.

You can import these Support Categories into Maica using our Reference Data Template, which is further explained .

Description

How do I configure Support Categories?

If you wish to configure your own Support Categories within Maica in order to set up and manage budgets correctly, please follow the steps indicated below.

1. Search for Support Categories in the App Launcher

In the Salesforce App Launcher, search for Support Categories and choose it to open the list view of all Support Categories records in your Maica instance, as shown below.

2. Create new Support Category

Once you are viewing your Support Categories, simply click the New button located in the top right hand corner of your interface to bring up the New Support Category pop-up, as shown below.

Note, you can also customise imported by Support Categories by simply selecting them and clicking the Edit button.

After the pop-up is displayed, you will be prompted to fill-in the following fields:

Field
Description

The Category Product field associates the Support Category to a specific Product. However, please note, it is not best practice on Maica to use the Category Product field when configuring Support Categories, rather, it is best practice to link Products Records to Support Categories directly from the Product record. This is further explained .

Once populated, simply click Save to create your Support Category.

3. Populate your Support Category with Support Items

Now that your Support Category has been set up, you must populate it with Support Items that correspond to the budget items in the package.

As mentioned above, this is not done through the Support Category, but rather, directly from the Support Item record.

Clicking the New on the Support Item related list directly from your Support Category record will create an entirely new Support Item, not assign an exisiting one.

In order to learn how to configure and assign Support Items to your Support Category, please click .

Maps Management

Learn about Maps Management Settings in Maica

These settings determine how Maica manages Maps and its function throughout the application. Please refer to the below table for more information on each setting:

Setting
Description

Setting Up Your Google API Key

The below section outlines the steps required to enable Google Maps functionality in Maica by setting up your own Google API Key, including enabling the necessary APIs and updating your Maica settings:

  1. Go to the Google Cloud Console

  2. Select your project In the top menu, select the project you’re working on (or create a new one if needed).

  3. Open the API Library a. In the left-hand menu, go to APIs & Services > Library b. Search for Routes API (you may also see Directions API if that’s part of your routing setup), followed by the Geocoding API.

  4. Enable the required APIs a. Click on and enable both the Routes API and Geocoding API

Please note, Google Maps APIs require billing to be enabled, even for free usage. If billing is not enabled, then:

  1. Go to Billing > Manage Billing Accounts

  2. Make sure billing is enabled on your selected project

  1. Get Your API Key a. Go to APIs & Services > Credentials b. Create or select an API key

  2. Update Maica Settings a. In Maica, go to Settings > Maps Management b. Paste your Google API Key into the Google API Key field and click Save.

Category
Interaction Type
Appointments
Duration
Appointments
Claim Type
Invoice Line Item

Solution Installation

The installation of the Maica solution into your Salesforce instance. Where applicable, we will assist you with getting access to your Salesforce environment.

If your Salesforce instance was purchased directly from Salesforce, you must ensure it is hosted in Australia. If Maica is provisioning your Salesforce instance for you, we will take care of this.

NDIS API Connection

The connection of Maica to the NDIS APIs where this is relevant.

An agreement with the NDIA must be signed prior to gaining access to ensure data integrity.

Scheduling & Rostering Setup

This provides the required Appointment Services to enable the scheduling and rostering engine of Maica including all relevant settings, preferences, and resources.

Maica provides a set of compliant Appointment Services for the NDIS and Aged Care under which your organisation can start delivering services without the need for any further configuration.

Reference Data Load

Setting up a set of required reference data for your organisation.

This includes Registration Groups, Support Categories, Support Items across NDIS and Aged Care.

End User Training

The solution training of your team, including usage of Maica across all functions of the lifecycle.

This is constrainted to a single 2 hour session.

Scheduling & Rostering Setup

This configures any relevant extensions to the scheduling and rostering engine of Maica including all relevant services, settings, preferences, resources, and security/profile configuration.

Core Data Model Extensions

This includes the extension of required attributes across existing Maica data objects, such as Contact, Service Agreement, and Appointment as well as the configuration of any newly determined data requirements.

Billing Flow Extensions

This is the extension development (using Salesforce Flows) of the standard Maica billing flows, including special billing conditions and recurring billing scenarios that might require amendments to Maica.

Timesheet Flow Extensions

This is the extension development (using Salesforce Flows) of the standard Maica timesheet flows to ensure that it is suitable for your organisational processes, including special award interpretation conditions.

Document Generation

The development of several digital documents (including digital signature) using the Conga Composer or DocuSign platforms.

Xero Finance System Extensions

The development of any required extensions to Maica’s native Xero integration where this is relevant.

Online Portal Development

The development of a secure online portal for either Participants or Providers to allow for self-management of Appointments, Invoices, etc. This typically requires custom branding and layouts to ensure your online presence is represented consistenly throughout.

Integrations Development

The development of various integrations to complement your Maica/Salesforce solutions, including systems such as KeyPay, SharePoint, Outlook, among other typical integrations we have come across.

Any Relevant Extensions Development

This includes the configuration and development of any relevant & required extensions to either the core Maica solution or the underlying Salesforce platform. This can include discovery workshops, architectural guidance, flow development among many other activities.

Salesforce
Extensions Implementation Process
request a trial
organise a demonstration
connect

Google API Key

This is your Google Maps API Key that can be set up in your Google administration platform. By using your own Google Maps API Key, it will be possible to report, within the Google platform, on all requests, locations, routes requested via Maica. To ensure Maica functions correctly, the following APIs must be enabled in your Google project:

  1. Routes API

  2. Geocoding API

For guidance on enabling these APIs and retrieving your API key, please refer to the section below.

Travel Warning Tolerance (Minutes)

Maica warns you if the required travel time exceeds to the available time prior to any given Appointment. In other words, if you are not going to make it on time, Maica alerts you to this via a warning icon. This setting defines the tolerance duration used to determine when this warning should display. An example might be setting this tolerance to 5 minutes which means that if Google estimates you to be late by more than 5 minutes, the warning will show.

Default Origin/Destination Order

This determines the order in which Maica calculates the distance and travel time required to get to/from any given Appointment. In other words, what origin and destination Maica will use first, second, and so forth to calculate the initial travel times.

https://console.cloud.google.com/

Billing Management

Learn about Billing Management Settings in Maica

These settings determine how Maica manages Billing and its function throughout the application. Please refer to the below table for more information on each setting:

Setting
Description

Service Time Prioritisation

Maica uses the date/time field(s) selected to determine the Appointment’s time bracket for billing purposes. You can select multiple values and their priority order (if the higher priority field has no value, the next field in descending order will be used).

Time Bracket Inclusivity

Define whether the Start or End of your defined Time Brackets are inclusive. When the Start is inclusive, Appointments starting on the bracket start value are included in that bracket. When End is inclusive, then Appointments ending on the bracket end value are included in that bracket. Typically the selected value should align to your selected billing priority date/time value. Eg. If inclusivity was set to “End”, an Appointment ended at 6:00am and your Night bracket ended at 6:00am and Day was set to start at 6:00am. The service would be considered as Night as opposed to Day. The reverse would be true if you selected “Start”.

Enable Rate Comparison

When this setting is enabled, Maica will compare the two Rates retrieved using the configured Service Time Prioritisation and Comparison values and return the one that matches your Rate Preference.

Time Travel Cap (minutes)

If a value is provided in this setting, Maica will limit any time-based billable travel to the minutes specified here. If travel caps are specified at Service Agreement level, this will take priority over this global setting.

Chargeable Travel Cap (kms)

If a value is provided in this setting, Maica will limit any non time-based billable travel to the kms specified here. If travel caps are specified at Service Agreement level, this will take priority over this global setting.

Short Notice Cancellation Period (days)

When Appointments are cancelled, Maica marks any associated Delivery Activities as cancelled for potential billing. This setting determines the period in which a cancellation will be billed, for example setting this to 4 means any Appointment within 4 days of the scheduled start date will be billed to the Participant.

Service Time Prioritisation for Comparison

Required when you enable Rate Comparison. This value will be used to retrieve a Rate for comparison against the Rate retrieved from the prioritised Service Time.

Rate Preference

When Rate Comparison is enabled, Maica will use the selected value to determine which returned Rate is used for Appointment costing and billing.

Invoice Auto-Creation

This determines how Invoices and Invoice Line Items are generated; options include Manual or Schedule. If Manual is selected, an authorised user will generate all required Invoices and Invoice Line Items.

Schedule Frequency

If Schedule is selected in the Invoice Auto-Creation setting, this determines the frequency at which Invoices and Invoice Line Items are generated.

Schedule Start Date

If Schedule is selected in the Invoice Auto-Creation setting, this determines the start date of the Invoice and Invoice Line Item generation process.

Schedule Time

If Schedule is selected in the Invoice Auto-Creation setting, this determines the time at which Invoices and Invoice Line Items are generated.

Invoice Flow

If Schedule is selected in the Invoice Auto-Creation setting, this determines the actual Salesforce Flow to be used to generate Invoices and Invoice Line Items. This could either be the native Maica Flow or any developed custom Flow.

Service Delivery Date Mapping

This determines the date from the Appointment being used on the Invoice Line Item, for example Schedule Start or Actual Start.

Client Note Schema
Timesheet Entry Schema

Flow Label

Maica - Recalculate Service Agreement Statement Screen Flow

API Name

maica__Maica_Recalculate_Service_Agreement_Statement_Screen_Flow

Type

Screen Flow

here

Flow Label

Maica - Resource Participant Trigger

API Name

maica__Maica_Resource_Participant_Trigger

Type

Autolaunched Flow

Load Order

1

Label

ResourceParticipantManualShare_MDTM

here

Name

This will be the name of your Appointment Service. As an Appointment Service is essentially a parent object for your Support Items, we recommend naming your Appointment Services generically based on the Support Items it will contain.

Claim Types

  • Available: Lists all potential Claim Types that can be associated with the Appointment Service.

  • Chosen: Select the relevant Claim Types for this Service that match the associated Support Items. Only selected Claim Types in this section will apply to the Appointment Service.

Tags

These are custom tags to categorise or group Appointment Services. Tags can assist in easy search and filter of Services when assigning a Service to an Appointment.

Available Sections

  • Available: Lists different sections that can be added to the appointment service.

  • Chosen: Select the sections relevant to this Service. This customises what fields or information will be displayed when setting up an Appointment using this Service.

Start & End Date

This field represents the beginning date (when the Appointment Service becomes active) and when the end date (when the Appointment Service is no longer valid). If the End Date is left blank, the Appointment Service will be active indefinitely.

Participant Note Template

  • Participant Note Template: This assigns a template for Participant Notes that will be associated with the Service. Select a pre-existing template or search for one to guide standard note-taking.

  • Pre-load Template: If checked, this option will automatically load the selected Note template whenever this Appointment Service is used.

here
Billing Flow
here

Active

Determines whether the Connection record is active and available to users. Only active Connections will appear when creating new relationships.

Name

The primary Connection name selected when creating a Connection from a Contact.

Male

The reciprocal Connection that will be generated if the Contact’s gender is classified as Male.

Female

The reciprocal Connection that will be generated if the Contact’s gender is classified as Female.

Neutral

The reciprocal Connection that will be generated if the Contact’s gender is classified as Neutral or is not set.

Billable Fees

Fees that are charged directly to a customer through a co-payment invoice.

Claimable Fees

Fees that the provider can claim on behalf of the Home Care Package.

Client Contributions

Money paid into the package directly by the client, such as a basic daily fee.

Subsidies

The base subsidy paid by the government into the Home Care Package budget.

Supplements

Additional pieces of funding that individual participants can acquire approval for, to help with specific needs.

Name

This will be the name of your Support Category. You can name your Support Categories anyway you wish.

NDIS Name

This is the official name of the support category as recognised by the NDIS (National Disability Insurance Scheme), if applicable. Note: As NDIS Support Categories are populated via the Data Import, this will be automatically be populated.

Support Purpose

The Support Purpose dropdown is a configurable field within a Support Category, to which new values have been added to represent the categories of budget items within a Home Care Package. It is important that before you begin adding products that represent actual budget items to the package, you first set up your support categories to support the creation of the products underneath.

Category Number

This field is a unique identifier or reference number for the Support Category.

Fund Management Type

Specifies the type of fund management associated with the Support Category, indicating how funds are managed for services under this category. If you are configuring Support Categories for Home Care Packages, please ensure this is set to Home Care Package.

here
here
here
Maica | Leading NDIS & Aged Care Software for Providers

Location

The Location object in Maica represents a Location where Services are delivered, i.e. office or home address

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Location object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Location Schema.

Automation

Flows

The list below outlines the Flows applied to the Location Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Location Geocoding

This flow is designed to geocode a location's address upon creation or update of the location record.

Flow Detail

Flow Label

Maica - Location Geocoding

API Name

maica__Maica_Location_Geocoding

Type

Autolaunched Flow

Flow Summary

This flow geocodes the address of a location and updates the location record with the latitude and longitude by:

  • Triggering on the creation or update of a location record.

  • Geocoding the address fields using an Apex action.

  • Checking for errors in the geocoding process.

  • Updating the location record with the geocoded latitude and longitude if no errors occur.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow is triggered upon the creation or update of a location record.

    • The flow runs asynchronously after the record is saved.

    • Proceeds to geocode the address.

  2. Geocode the Address (Apex Action):

    • Calls the GeocodeAddressInvocableProc Apex action to geocode the address fields.

    • Passes the address fields and the record ID as input parameters.

    • Proceeds to the decision step to check for errors.

  3. Error? (Decision):

    • Checks if there was an error during the geocoding process by evaluating the errorMessage from the Geocode_the_Address action.

    • No: If no error, proceeds to update the location.

    • Yes: If an error occurred, the flow ends without updating the location.

  4. Update Location (Record Update):

    • Updates the location record with the latitude and longitude values obtained from the geocoding process.

    • Ends the flow.

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Location Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Location Geocoding

This trigger is designed to manage the geocoding of locations in Maica.

Detail

Load Order

1

Label

LocationGeocode_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the LocationGeocode_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the geocoding process for locations.

  • Trigger Conditions:

    • When a new location (maica__Location__c) is created.

    • When an existing location is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a location record is created or updated, the trigger is initialised. The LocationGeocode_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the LocationGeocode_MDTM class.

    • The class methods perform the following steps:

      • Validation: The location address data is validated to ensure it is complete and accurate.

      • Geocoding: The validated address data is converted into geographical coordinates using geocoding services.

      • Update: The location record is updated with the newly obtained geographical coordinates.

Trigger Outcome:

Once executed, the trigger ensures that each location is geocoded correctly, based on the logic defined in the handler class. This helps maintain accurate geographical data for locations.

Import Template

Learn how to Import your Reference Data Template into Maica

How do I import my Template?

Once you have completed your Reference Data Template, you can import it into Maica using Maica's Data Import Utility Tool.

First, you must export your Template as a CSV file.

Your Reference Data Template will be comprised of many tabs (one for each Data Object supported), you can only import one tab at a time into Maica and it must be in a CSV format.

Once you have exported your Template out of Google Sheets or Excel (whichever you prefer to use), you will be ready to import it into Maica.

To complete the import, use the Data Import Utility Tool that is described here.

When importing Reference Data into Maica you must select Maica - Reference Data Import Handler as the Flow Setting. If you are unsure what a Flow Setting is, please refer to our article on the Data Import Utility. To learn more about the logic behind the Flow itself, click here.

Once you have chosen the correct Flow Setting and uploaded your file, but before you finalise your import, we recommend ticking the Check Only box. As explained in the Data Import Utility article, the Check Only checkbox replicates the data uploading process. This means you may check for mistakes before transferring data to Maica. If there are any errors, you will get an Error Report.

Once you have checked and finalised your file, uncheck this box and press import to start the upload process.

Allowing Parallel uploads will speed up the process, but we do not suggest it because it may cause Record Lock difficulties.

After you have imported your data, you will see a successful display message indicating that the import has been completed, as shown below.

Error Handling

After each import execution, Maica will display the number of successful rows as well as the number of failed rows. If there are any failures, an Error Report will be available for download.

The error report will include a complete list of failed rows as well as an explanation for each failure.

You can then repair any data errors and reload the failed rows to finish your data load.

Please refer to the table below for an outline of some common errors that may arise when importing your Reference Data Template

Import Sequence

Due to relationships between Objects in Maica, some Data Objects being imported may have a Related Record Name field. This essentially means that certain Objects will have columns in their Reference Data Template that call for the Name Value of a related Object. This Value represents a lookup field linking the record to another related record. In the Reference Data importing process we use the Name Value from the related Object to search for, find and relate the imported record.

As a result, certain Objects need to be imported prior to others that may be searching for a related record.

For example: A Price Book Entry will rely on a Product, hence Products must be imported into Maica prior to Price Book Entries. This is because you need Products to create a Price Book Entry, which is shown in the Price Book Entry Template through the Related Record Name column of Product Name, as shown below. Hence, when importing Price Book Entries into Maica, the system will search for the related Products that must have been previously imported.

Please note that Price Book Entries may be called Price List Entries in your Maica instance, and Products may be called Support Items. The logic is unchanged.

The logic below outlines the Data Object relationships and the required import order of each of them.

// Primary Object Relationships

Products -> PriceBook -> PriceBookEntry -> AppointmentService

// Additional Object Relationships

Connections -> Contacts
Unavailability, Availability -> Resource
ResourceSkills -> Resource
ParticipantGoals -> Contacts
ShiftResources -> Shifts
ChecklistItems -> Checklist

Contacts (Participants) are not imported using the Reference Data Template, but rather configured directly in Maica. However, it is important that you configure your Contacts prior to Importing Reference Data.

The above logic shows that each object (or group of objects) on the right depends on the object (or group of objects) on the left. Arrows (->) indicate the dependency, meaning the object on the left must be imported before the object on the right can be correctly imported or used.

Common Errors

The table below describes some common errors and solutions that can occur when attempting to import a Reference Data Template into Maica.

Click here to view and download the complete Reference Data - Common Errors sheet

General Settings

Learn about General Settings in Maica

These settings determine how Maica manages General Settings and their function throughout the application. Please refer to the below table for more information on each setting:

Setting
Description

Maica Managed Sharing

Salesforce offers a security mechanism called which allow you to configure access for particular users to specific records in Salesforce.

This setting enables Maica to automatically create or remove a Salesforce Sharing Rule for a Resource when a Resource Participant (on the Resource’s profile) is added or removed.

Note: For this setting to function correctly, the Contact sharing model must be set to Private. Otherwise, all users may already have access to all Contact records, making sharing rules unnecessary or ineffective. To learn how to set the Contact sharing model to Private, refer to the section .

Allow Saving when Validation Rule is triggered

Salesforce offers a validation mechanism called which allow you to configure specific validations, such as field masks and mandated values. This setting enables/disables Maica to adhere to any Salesforce Validation Rules configured against the Appointment record and, if triggered, prevent the creation/management of an Appointment.

Schedule Horizon

When creating recurring Appointments or Shifts, Maica will generate the relevant records in advance for you but this will be a rolling generation limited by the Schedule Horizon. As an example, by setting the Schedule Horizon to 4 weeks, your recurring Appointments/Shifts will be generated 4 weeks in advance at any one time.

Time Bracket Configuration Settings

Please refer to the below table for more information on each setting:

Setting
Description

Time of Day

When billing, particularly within the NDIS, there may be multiple for the same service but different times, for example a Support Item for a 10am service might be different to a Support Item for the same service at 3pm. As such, Maica needs to know what time falls into what bracket, for example 3pm is considered to be Afternoon and so forth. This setting defines the various time brackets and their corresponding service times for the purposes of billing.

Prioritisation

This setting defines which order Maica will use when a time falls into multiple time brackets so the most relevant Support Item is selected for the purposes of billing.

Enabling Maica Managed Contact Sharing

Follow the steps below to configure your Salesforce org for Maica's Contact Sharing model.

Note: Maica’s managed sharing applies to Contact records only. If your organisation requires managed sharing for other objects, this would need to be handled outside of the Maica package.

Contact records must be associated with an Account in order for sharing to apply. If a Contact does not have an Account, Salesforce will not apply any sharing rules—even if Maica Managed Sharing is enabled. This is a known Salesforce behaviour.

To fix this, either:

  • Enable Person Accounts in your org, or

  • Automatically assign a default Account to Contacts with no Account using a Flow (If you need help with this - please contact Maica Support).

Step 1: Set Contact Sharing to Private

  1. Go to Setup in Salesforce.

  2. In the Quick Find box, search for and select Sharing Settings.

  3. In the Organisation-Wide Defaults section:

    • Either select Contacts from the Manage sharing settings for dropdown, or

    • Click Edit and locate Contact in the list.

  4. Set both Internal Access and External Access for Contact to Private.

  5. Click Save if prompted.

When the sharing model for Contacts is set to Private, a user can only see Contact records that they own or that are explicitly shared with them—either directly, via role hierarchy, manual sharing, sharing rules, or team access. This is the default and recommended setting for Maica.

Check the Profiles that Override Contact Sharing list. If any user profile has ticks here, those users will be able to view and modify all Contact records regardless of sharing settings. This may be appropriate for System Administrators, but should not be enabled for standard users.

Step 2: Enable Maica Managed Sharing

  1. Navigate to Maica Settings in Salesforce.

  2. Under the General Settings section, locate the Maica Managed Sharing setting (explained above).

  3. Click Edit.

  4. Toggle the setting on.

  5. Click Save.

Note: It may take a few minutes for any changes to take effect.

Sharing Records

Contact sharing is managed via the Resource Participants object. In the example below, you can see that the Contact Yuri Green has been shared with this user:

To share another Contact:

  1. Click New in the top-right corner of the Resource Participants section on the Contact record.

  2. In the pop-up, select the appropriate Resource and Contact.

  3. Set a Start Date for the access.

  4. (Optional) Add an End Date if you want access to be removed automatically on a specific date. Most users will leave this blank.

  5. Click Save.

Once saved, the selected Contact will be visible to the user associated with the Resource. For example, if you add Sarah Milne, that user will now have access to both Yuri Green and Sarah Milne’s records—along with any Contacts they own or that have been manually shared with them.

Delivery Activity

A Delivery Activity in Maica captures services delivered to a participant/client including the support item to bill, duration, and date information.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Delivery Activity object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Delivery Activity Schema.

Automation

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Delivery Activity Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Delivery Activity Appointments

This trigger is designed to manage the association of delivery activities with appointments in Maica. The outcome is accurate and reliable data for all delivery activities and their associated appointments, ensuring proper management and reporting.

Detail

Load Order

1

Label

DeliveryActivityAppointments_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the DeliveryActivityAppointments_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the association process for delivery activities and appointments.

  • Trigger Conditions:

    • When a new delivery activity (maica__Delivery_Activity__c) is created.

    • When an existing delivery activity is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a delivery activity record is created or updated, the trigger is initialised. The DeliveryActivityAppointments_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the DeliveryActivityAppointments_MDTM class.

    • The class methods perform the following steps:

      • Validation: The delivery activity data is validated to ensure it is complete and accurate.

      • Association: Delivery activities are associated with the correct appointments based on predefined criteria such as activity type and appointment details.

      • Update: The delivery activity record is updated with the associated appointment data.

Trigger Outcome:

Once executed, the trigger ensures that each delivery activity is associated with the correct appointment, according to the logic specified in the handler class. This helps maintain accurate delivery activity and appointment data.

Delivery Activity Invoices

This trigger is designed to manage the invoicing for delivery activities in Maica. Ensures correct generation of invoices for delivery activities, maintaining accurate invoicing data.

Detail

Load Order

2

Label

DeliveryActivityInvoices_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the DeliveryActivityInvoices_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the invoicing process for delivery activities.

  • Trigger Conditions:

    • When a new delivery activity (maica__Delivery_Activity__c) is created.

    • When an existing delivery activity is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a delivery activity record is created or updated, the trigger is initialised. The DeliveryActivityInvoices_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the DeliveryActivityInvoices_MDTM class.

    • The class methods perform the following steps:

      • Validation: The delivery activity data is validated to ensure it is complete and accurate.

      • Invoice Generation: Based on the delivery activity details, invoices are generated to reflect the services provided.

      • Update: The delivery activity record is updated with the newly generated invoice data.

Trigger Outcome:

Once executed, the trigger ensures that each delivery activity has its invoices generated correctly, according to the logic specified in the handler class. This helps maintain accurate invoicing data for delivery activities.

Overnight and 24 Hour Availability

Learn how to configure Overnight Availability in Maica

How do I set up Overnight Availability Records?

To enable Overnight or 24 Hour Availability for a Resource, you must first properly configure an Operating Hour Record. To do so, follow the steps outlined below.

As Maica creates Availability by referencing Operating Hour records, it is critical to appropriately configure an Overnight or 24 Hour Operating Hour record before attempting to plan a Resource's Availability.

1. Search for Operating Hours in the App Launcher or directly from the Resource

In Maica, there are two ways to create your Operating Hours record, these are:

  • Through the Salesforce App Launcher

  • Directly from the Resource Availability Record

Follow the steps below to see how they both work:

1. Salesforce App Launcher

In the Salesforce App Launcher, search for Operating Hours.

Then, simply select it to open the list view of all Operating Hours in your Maica instance, as shown below. Click New to begin populating your record.

2. Through the Resource Availability Record

Navigate to a Resource you wish to create an Overnight or 24 hour Availability record for. Then, under Availability, click New.

This will bring up the New Availability module, as shown below. Once here, navigate to the Operating Hours field, select it as if you were to assign an Operating Hours record, and click New Operating Hour.

2. Create new Operating Hours Record

After the pop-up is displayed, you will be prompted to fill-in the following fields:

Field
Description

To configure the Operating Hours records that enable overnight or 24-hour Availability for Resources in Maica, you will need to follow slightly different processes.

See the respective sections below for further information on each one.

24 Hour Availability Configuration

To set up an Operating Hour record to allow for 24 hour Availability, you need to set up the record so that:

  • The Start Time and End Time are the same (e.g., 12:00 AM to 12:00 AM).

  • The selected weekdays define the active period (e.g., selecting Monday and Tuesday allows bookings spanning from Monday through to Wednesday).

The system allows appointments to be booked across multiple days as long as they do not exceed the defined maximum (e.g., 48 hours if two consecutive days are selected).


For example:

If you wanted to book a Resource for an overnight Appointment on Mondays and Tuesdays, meaning they can take appointments that span Monday through Wednesday, then:

  1. Assign an Operating Hour record with the following inputs:

    • Name: "Organisation Preference"

    • Weekday: Monday, Tuesday

    • Start Time: 12:00 AM

    • End Time: 12:00 AM

  2. Save the record.

Note,

  • If a user tries to book an appointment beyond the allowed range (e.g., past Wednesday in this case), Maica will not allow it.

  • If a non-consecutive day is selected (e.g., Monday and Wednesday but not Tuesday), the system prevents bookings that cross the missing day.

Overnight Availability Configuration

To set up an Operating Hour record to allow for Overnight Availability, you need to configure the record so that:

  • The End Time is earlier than the Start Time (e.g., 6:00 PM to 6:00 AM).

  • A single weekday is selected, meaning the availability will carry into the following day.

Maica recognises overnight availability when the End Time is before the Start Time, allowing availability to extend past midnight into the next day.


For example:

If you wanted to book a Resource for an overnight shift that starts on Monday at 6:00 PM and runs until Tuesday at 6:00 AM, then:

  1. Assign an Operating Hour record with the following inputs:

    • Name: "Organisation Preference"

    • Weekday: Monday

    • Start Time: 6:00 PM

    • End Time: 6:00 AM

  2. Save the record.

3. Assign Availability to the Resource

Once the Operating Hour record has been created, the next step is to assign it to a Resource’s Availability. This ensures that the Resource follows the configured operating hours when scheduling Appointments.

Once your Availability Record has been created with the correctly configured Operating Hours, you will be ready to schedule Overnight or 24 Hour Appointments.

Create a Site

Learn how to Create a Site in Maica

What is a Site in Salesforce?

In Salesforce, a Site:

Enables you to create public websites and applications that are directly integrated with your Salesforce organisation—without requiring users to log in with a username and password. You can publicly expose any information stored in your organisation through a branded URL of your choice.

Sites are critical for securely sharing data and integrating with external systems while maintaining control and security over the exposed functionality.

To learn more about Sites in Salesforce, click .

Why are they important in Maica?

In Maica, a Site is essential for enabling successful and automated integrations with external platforms like Xero, Stripe, and NDIS through webhooks.

The Site essentially acts as a public-facing endpoint that the external systems can communicate with to send and receive real-time updates, such as payment confirmations or notification handling. In this context, the Site facilitates the secure exchange of data by exposing specific parts of the Maica environment to these external platforms, allowing them to trigger actions in Maica (e.g., updating participant records or processing payments) without requiring manual intervention.

By using webhooks, the integration becomes more efficient and automated, as events are instantly relayed between systems, ensuring timely and accurate updates across all platforms.

So, before we can configure any integration on Maica, we must ensure our Site is created and set up correctly.

How do I create a Site?

In order to effectively create a Site in your Salesforce instance, please refer the following Salesforce articles:

Things to look out for: Sites in Maica

1. Site Fields

Once your Site has been created, there are a few components necessary for ensuring they are successful in Maica and your integrations.

Field
Description

In addition, ensure the below boxes are checked and you use the recommended Clickjack Protection Level.

2. Site Timezone

Once you have configured your Site fields and assigned the appropriate naming conventions, it is important to assign the correct timezone to your Site Guest User.

When you create a Salesforce Site, Salesforce automatically generates a Guest User for that site. The guest user profile allows public access to the site for unauthenticated users, such as visitors or external systems interacting with your site.

You do so by heading to the your Site Profile.

To get your Site Profile, follow the below listed steps:

  1. Select Your Site: In the list of your sites, find the site that you set up (in our case, the one called Maica Notifications) and click on the Site Label.

  2. View the Site Details: On the site details page, click on the Public Access Settings button.

  3. Navigate to the Profile: This link will take you to the Site Guest User Profile for that site. You can then click Assigned Users to see the Site Guest User associated with the site.

Once there, select the Full Name in order to assign the correct timezone to your Site Guest User, as shown below.

Maica Notifications Profile is the profile that defines what the guest user can access, including permissions for objects, fields, and other settings.

After selecting your Site Guest User, simply click Edit and change the timezone to Australian Eastern Standard Time (or your relevant Time Zone), as shown below.

Setting the correct timezone for the Site Guest User ensures that data synchronised between Maica and external platforms is timestamped consistently, improving accuracy, compliance, and reliability across both systems.

3. Assign Permission Sets

As well as setting the correct timezone for our Site Guest User, it is important to assign the relevant permission sets in order to make Integrations work seamlessly. You do this from the same Profile as shown above.

Once on the Site Guest User Profile, simply scroll down Permission Set Assignments and click Edit Assignments. Here, you can add the relevant Permissions for your Organisations Integrations, the relevant Permissions are as follows:

Permission Set
Description

Travel Management

Learn about Travel Management Settings in Maica

These settings determine how Maica manages Travel and its function throughout the application. Please refer to the below table for more information on each setting:

Setting
Description

Time-Based Cost Management & Non-Time Based Cost Management

When managing billable travel, there are two foundational components to this process:

  • Time-Based Travel – Travel billed based on time spent traveling to and from an appointment.

  • Non-Time-Based Travel – Travel billed based on distances traveled (e.g., kilometers).

These settings determine, for each Funding Structure which way Maica will generate the relevant billing records for travel.

Setting
Sub-Setting
Description

Primary Support

In Maica, when Travel Management is enabled, the system determines the correct Travel Support Item based on the Primary Support Appointment Service.

  • The first selected Appointment Service in an Appointment is always the Primary Support.

  • The Primary Support is identified in Maica by the starred Appointment Service in the Appointment modal.

  • Travel items are determined based on the Primary Support’s Claim Type or Support Item.

So, how are Travel Support Items assigned? Well, as mentioned, when scheduling an Appointment, the first selected Appointment Service is by default the Primary Support. This means for:

Time-Based Assignments: Maica looks for the related Claim Type or Support Item within the specified Appointment Service in settings.

and for Non-Time Based Assignments: Maica also looks for the related Claim Type or Support Item within the specified Appointment Service in settings.

So, when an Appointment Service is specified in the Settings, Maiac's logic will select the Primary Support Item and then locate the required Travel Support Item by matching on Category and Registration Group.

If the Appointment Service contains Support Items that do not have Support Categories or Registration Groups, matching logic will not be applied.

For example, if:

  • Primary Appointment Service: 01 Self Care

  • Primary Delivery Activity:

    • Assistance With Self-Care Activities – Standard – Weekday Night (01_799_0107_1_1)

  • Time-Based Delivery Activity:

    • Provider Travel – Non-Labour (01_002_0107_1_1)

    • Claim Type: Provider Travel

  • Non-Time-Based Delivery Activity:

    • 01_799_0107_1_1 (from Primary Support)

Then,

  • Maica recognises "01 Self Care" as the Primary Support.

  • It assigns Time-Based Travel by checking the Claim Type OR Support Item within the Primary Support.

  • It assigns Non-Time-Based Travel by checking the Claim Type OR Support Item and, if applicable, matching on Category and Registration Group.

If no matching support item is found, the system sets the Delivery Activity Billing Status to Review for further validation.

This example demonstrates the typical billing outcomes when Travel Management is enabled and charge for both Time and Non-time based activities is selected.

Selecting your Primary Support

To reorder your Appointment Services, and hence determine the Primary Support, you can use the arrow on any applicable Appointment Service. As shown below.

To Note:

  • Empty Appointment Services are excluded from being nominated as the Primary Support.

  • Appointment Services where the Claim Type is equal to the Time Based , Non Time Based or Same Appointment Service Travel Setting Claim Type are also excluded.

  • When an Appointment contains multiple Participants, there can only be one Primary Support selected, hence it will apply to all Participants.

Name

A descriptive name for the Operating Hour record.

Weekday

The day(s) of the week when this operating hour applies. You can select one or multiple days.

Start Time

The time when the operating hour begins for the selected weekday(s).

End Time

The time when the operating hour ends for the selected weekday(s).

Site Label & Site Name

This is the name of the site as it appears in the user interface. We recommend a generic term to suit all integrations: such as Maica Notifications.

Default Web Address

This is the unique Salesforce Site URL for this site. We recommend a generic term to suit all integrations: such as Notifications.

Active

Ensure this field is checked so the Site is Active upon Save.

Maica - Handle Webhook Notifications

Provides the ability to process the Webhook Notifications.

here
Enable Salesforce Sites
Setup Salesforce Sites
Create and Edit Salesforce Sites
Configure Salesforce Sites

Enable Travel Management

This either enables the automated travel calculation or disables it which then means that all travel will be calculated either manually or via custom-developed logic.

Reimbursement Rate

This is the financial rate used to generate the expense claim record for any Resource during the management of travel costs.

Default Expense Status

When Maica generates expense claim records for any Resource, this sets the default status used for such expenses.

Chargeable Travel

This determines which parts of travel are to be charged to a Participant's Service Agreement; options included Only charge to the Appointment, Only charge from the Appointment, Don't charge, Charge for travel to and from the Appointment.

Payable Travel

This determines which parts of travel are to be paid to any Resource as an expense; options included Only pay to the Appointment, Only pay from the Appointment, Don't pay, Pay for travel to and from the Appointment.

Travel Claim Type

When Maica automatically generates an additional Appointment Service (if selected below) for billing purposes, the Travel Claim Type determines the Claim Type assigned to this service.

Travel Timesheet Activity

When Maica generates an corresponding Timesheet Activity for travel, this determines which Support Item (marked as a Timesheet Activity) will be used.

Previous/Next Appointment Timespan (days)

Maica uses Google to calculate travel times between a source and destination; these can be various options such as Current Location, Primary Location, Manual Address, and Previous Appointment. This setting determines how far back (in Days) Maica goes to find any applicable previous Appointment.

Funding Type

Funding Structure

For each combination of Funding Type and Funding Structure, such as NDIS -> Agency Managed or HCP -> Home Care Packages, this determines which method Maica will use to bill for travel.

Sharing Rules
below
Validation Rules
Support Items
Checklist Schema
Log Schema
Availability Schema
Preference Schema
Support Category Schema

Connections Management

Learn about Connections Management Settings in Maica

These settings determine how Maica manages all Connections and their function throughout the application.

To dive deeper into each of the Connections Settings, please visit their specific pages linked below:

  1. General Settings

  2. Reciprocal Settings

Maica Permission Sets Matrix
Finding your Maica Edition
Timesheet Schema
Price List Entry Schema
Shift Schema
Price List Schema

Support Item

This object in Maica represents the Services to be delivered and are associated Support Categories.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Support Item object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Support Category Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Shift Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Key NDIS Attributes Required When Funding Source is NDIS

Ensures key NDIS attributes cannot be null if the Funding Source equals NDIS

Validation Rule Detail

Rule Name

VAL_SUPPORT_ITEM_0001

Error Message

VAL_0001: When the Funding Source is NDIS, the following fields are required: Support Category, PACE Support Category, Support Item Number, Service Day, Service Time.

Error Location

Top of Page

Error Condition Formula
AND(
    ISPICKVAL(maica_cc__Funding_Source__c, "NDIS"),
OR(
    ISBLANK(maica_cc__Support_Category__c),
    ISBLANK(maica_cc__PACE_Support_Category__c),
    ISBLANK(maica_cc__Support_Item_Number__c),
    ISPICKVAL(maica_cc__Service_Day__c, ""),
    ISPICKVAL(maica_cc__Service_Time__c, "")
)
)

Category Support Item or Bucket Cannot Be Related to Appointment Service Record

Ensures that a Category Support Item, or Bucket, cannot be related to an Appointment Service record.

Validation Rule Detail

Rule Name

VAL_SUPPORT_ITEM_0002

Error Message

VAL_0002: A Category Support Item, or Bucket, cannot be related to an Appointment Service record.

Error Location

Appointment Service

Error Condition Formula
AND(
    maica_cc__Bucket__c = TRUE,
    NOT(ISBLANK(maica_cc__Appointment_Service__c))
)

Automation

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Support Item Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Support Item Service Validation

This trigger is designed to manage the validation of support item services in Maica.

Detail

Load Order

1

Label

SupportItemServiceValidation_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the SupportItemServiceValidation_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the validation process for support item services.

  • Trigger Conditions:

    • When a new support item (maica__Support_Item__c) is created.

    • When an existing support item is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a support item record is created or updated, the trigger is initialised. The SupportItemServiceValidation_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the SupportItemServiceValidation_MDTM class.

    • The class methods perform the following steps:

      • Validation: The support item data is validated to ensure it is complete and accurate.

      • Compliance Check: The support item is checked for compliance with predefined service criteria, ensuring that it meets all necessary standards and requirements.

      • Update: The support item record is updated with the validation results, indicating whether it has passed or failed the validation checks.

Trigger Outcome:

Once executed, the trigger ensures that each support item service is validated correctly, according to the logic specified in the handler class. This helps maintain accurate and compliant support item data.

Support Item Unit of Measure

This trigger is designed to manage the unit of measure for support items in Maica.

Detail

Load Order

1

Label

SupportItemUnitOfMeasure_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the SupportItemUnitOfMeasure_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the unit of measure setting process for support items.

  • Trigger Conditions:

    • When a new support item (maica__Support_Item__c) is created.

    • When an existing support item is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a support item record is created or updated, the trigger is initialised. The SupportItemUnitOfMeasure_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the SupportItemUnitOfMeasure_MDTM class.

    • The class methods perform the following steps:

      • Validation: The support item data is validated to ensure it is complete and accurate.

      • Unit of Measure Setting: Based on predefined criteria, the unit of measure is set or updated for each support item, ensuring that it meets all necessary standards and requirements.

      • Update: The support item record is updated with the unit of measure details, indicating whether it has passed or failed the validation checks.

Trigger Outcome:

Once executed, the trigger ensures that each support item has its unit of measure set or updated correctly, according to the logic specified in the handler class. This helps maintain accurate and consistent unit of measure data for support items.

Planner Management

Learn about Planner Management Settings in Maica

These settings determine how Maica manages the Planner and its function throughout the application. Please refer below for more information on each setting:

Please note, the below settings can be applied to both Appointments and Shift separately and these will render in the Maica Planner in accordance with how they have been defined for either.

Text Format

Please refer to the below table for more information on each setting:

Setting
Description

Text Format

The Maica Planner allows you to specify what text appears in the cells of either an Appointment or a Shift.

This settings defines this by using a formula-based approach in which you can configure exactly what you want the text to be. This includes the merging of record attributes as well as your own text.

Appearance Settings

The Maica Planner allows for a variety of configuration options including colour branding and appearance as shown in the below screenshot.

A typical Appointmnent/Shift

Please refer to the below table for more information on each setting:

Setting
Description

Main Cell Colour

The Maica Planner allows you to set the cell colour based on any attribute from the Appointment/Shift (as long as this is a picklist) and then you can assign a specific colour for for each value. An example might be using an attribute called Status and then assigning a specific colour to each possible value of the Status such Planned or Scheduled.

Cell Indicator Colour

The Maica Planner allows you to set the cell indicator based on any attribute from the Appointment/Shift (as long as this is a picklist) and then you can assign a specific colour for for each value. An example might be using an attribute called Status and then assigning a specific colour to each possible value of the Status such Planned or Scheduled.

Shift Colour

This is the cell colour used to show Shifts within the Planner Schedule and Participant views.

Unavailability Colour

Maica allows Resources to record Unavailability and this setting defines what colour these Unavailability records are shown in.

Unfilled Appointment Colour

Maica considers an Appointment to be unfilled when either the number of Participants or the number of Resources is less than the Ratio specified. This setting specifies the cell border colour of Appointments that are marked as unfilled.

Cell Border Colour

This is the cell border colour used to show Appointments within the Planner Schedule and Participant views.

Cell Border Radius

The Maica Planner allows you to specify the width of the radius of each Appointment cell. This setting specifies the width of the radius from no radius (set to 0) to any desired width (set to greater than 0).

Other Settings

Please refer to the below table for more information on each 'Other' Setting:

Setting
Description

Field to be shown as the Participant Name

In the Maica Participant View (when selecting Timeline), all your active Participants are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Participant (Contact) profile to display as a replacement of the name of the Participant.

Field to be shown as the Resource Name: Appointment

In the Maica Schedule View (when selecting Timeline), all your active Resources are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Resources profile to display as a replacement of the name of the Resources.

Field to be shown as the Asset Name

In the Maica Asset View (when selecting Timeline), all your active Assets are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Asset profile to display as a replacement of the name of the Asset.

Field to be shown as the Resource Name: Shift

In the Maica Roster View (when selecting Timeline), all your active Resources are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Resources profile to display as a replacement of the name of the Resources.

Field to be shown as the Shift Name

In the Maica Shift View (when selecting Timeline), all your active Shifts are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Shift record to display as a replacement of the name of the Shift.

Field to be shown below the Participant Name

In the Maica Participant View (when selecting Timeline), all your active Participants are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Participant (Contact) profile to display below the name of the Participant.

Field to be shown below the Resource Name: Appointment

In the Maica Schedule View (when selecting Timeline), all your active Resources are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Resources profile to display below the name of the Resources.

Field to be shown below the Asset Name

In the Maica Asset View (when selecting Timeline), all your active Assets (Non-Human Resources) are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Resources profile to display below the name of the Resources.

Field to be shown below the Resource Name: Shift

In the Maica Roster View (when selecting Timeline), all your active Resources are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Resources profile to display below the name of the Resources.

Field to be shown below the Shift Name

In the Maica Shift View (when selecting Timeline), all your active Shifts are shown on the left had side of the Planner.

This setting allows you to select an attribute from the Shift record to display below the name of the Shift.

Quick Information Dialog Fields

The Quick Information Dialog in an interactive component that allows you to quickly engage with an Appointment or Shift without having to open the management console.

This setting determines what attributes (fields) are shown on this Quick Information Dialog when single-clicking on an Appointment or Shift.

Quick Information Dialog Actions

This setting determines what actions (such as Check-in) are shown on this Quick Information Dialog when single-clicking on an Appointment or Shift.

Shared Settings

Please refer to the below table for more information on each Shared Setting:

Setting
Description

Snap Size

This setting allows you to set the number of minutes that an Appointment or Shift is moved when dragging. An example might be setting this to 15 which means everytime an Appointment or Shift is dragged on the Planner, it is moved by 15 minutes.

Available Views

This setting specifies which Planner Views (like Schedule, Participant, or Shift) you would like your users to have access to. For example, if your organisation does not manage Shifts, then simply turn the Shift and Roster view off.

Unfilled Section Position

The Maica Planner shows a dedicated row for any Appointments or Shifts that are unfilled or unassigned. This setting determines whether this row is shown at the top of the Planner (in Timeline view), at the bottom or not at all

Timeline

This settings defines what time duration should be shown on the Planner, for example if 9am - 5pm is selected, then the Planner will render only these times. Use this setting to effectively represent your organisational working hours to be shown in the Planner.

Block Unavailability

Maica is able to either allow Appointments to be created when they overlap with a Resource's Unavailability or to block this from happening. This setting defines how Maica will behave when an Appointment is created during an Unavailability for any associated Resource.

Include Travel Time in Appointments

When rendering Appointments or Shifts in the Maica Planner, it is possible to either include the travel time into the Appointment or not. For example, your Appointment might be 60 minutes long with 30 minutes travel time. Depending on this setting, the Appointment is either shown as 60 minutes (if travel time is not shown) or as 90 minutes (if travel time is shown).

Cascade Look

The Maica Planner can render a number of overlapping Appointments either as sitting side by side or by cascading them on top of each other. This setting determines how the Maica Planner renders overlapping Appointments/Shifts.

Quick Information Dialog vs Tooltip

This determines whether the Maica Planner shows a tooltip when hovering over an Appointment/Shift or the Quick Information Dialog is shown instead.

Handle BPR Results & Remittance Files

Learn how to manually handle Payment Requests via the BPR Results and Remittance files

In the previous article, we covered how to generate and download the Bulk Payment Request (BPR) File.

This article outlines the next two steps in the process:

  • Importing the Bulk Payment Request Results File

  • Importing the Bulk Payment Request Remittance File

Bulk Payment Request Result File

Once the BPR File has been downloaded from Maica and uploaded to the myplace Provider Portal for processing, PRODA generates a corresponding Results File. This file contains key status details for all Payment Request records (rows) included in your BPR File.

From our experience, the Bulk Payment Results File is generally available for download within 20 to 30 minutes after upload.

The Results File contains the Status returned by PRODA for each Payment Request (row) uploaded in the initial BPR File. The two possible Status values are:

  • SUCCESSFUL

  • ERROR

For records with an ERROR, a Rejection Reason is provided to explain the issue.

In addition, the Results File includes:

  • The Paid Total Amount.

  • Whether a Capped Price has been applied by the Agency.

Importing the Results file via Maica

Once you’ve downloaded the Bulk Payment Request Results File, the next step is to import it back into Maica. This process updates the Status of each Payment Request record included in the initial BPR File, aligning it with the PRODA Status contained in the Results File.

To do so, you will need to:

  1. Click on the App Launcher in Maica.

  2. Search for Data Import.

As shown below.

Next, using the Upload Files feature, select the Results File you wish to import into Maica. Next, click on the Flow Setting dropdown and select NDIS Bulk Payment Request Results File. You can see an example of this below.

To learn more about the Data Import Utility in Maica, click here.

Lastly, click the Import button to process each row in the Results File. This will update the corresponding Payment Request records by matching them to the unique Claim Reference Index (maica__Claim_Reference_Index__c) generated.

The Claim Reference Index is a copy of the Claim Reference (Formula) field, optimised for high data volume processing as it is indexed by Maica.

BPR Results File - Field Mapping

For each Payment Request record in Salesforce, the Results import will update the Status as per the following:

Results File Column
SF Payment Request Field
Mapping Notes

Claim Reference

Claim Reference Index

Used to retrieve the Payment Request record. No update

Payment Request Status

Status

IF SUCCESSFUL = Pending Payment IF ERROR = Rejected

Error Message

Error Details

Mapped to this field as the Reject Reason picklist is used for API error.

All other columns in the BPR Results file are skipped as part of the Salesforce import

Bulk Payment Remittance Result File

The final step in the Bulk Payment Request Claiming process is to upload the Remittance File when it is received from the NDIA.

This process follows the same steps as described for the Results File (see above). However, in this case, you’ll need to:

  1. Upload the received Remittance File.

  2. Select the NDIS Remittance Advice Import Flow Setting, as shown below.

The Total Amount paid by the NDIA for the Payment Request, along with the date the funds were deposited into your organisation's nominated account, will be updated in the Paid Amount and Paid Date fields, respectively.

BPR Remittance File - Field Mapping

The Remittance File updates Payment Request records in Salesforce slightly differently compared to the Results File. Only records with a Status of Pending Payment will be updated.

Essentially, the Remittance File contains details of successful Payment Request records only.

Any Payment Request records with a Rejected status (as set by the Results File import) will not be updated by the Remittance import.

For each Payment Request record in Salesforce, the Remittance import will update the following:

Remittance File Column
Payment Request Field
Payment Request Field

ProvClaimRef

Claim Reference Index

Used to retrieve the Payment Request record. No update

AmountPaid

Paid Amount

No column mapping

Status

Paid

No column mapping

Paid Date

Set to TODAY

Funding

Represents the specific details of a Participant's funding, i.e. NDIS Funding or Home Care Package.

Depending on your Maica package, this Data Object may be called Plan in your organisation

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Funding object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Funding Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Funding Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

End Date Must Be After Start Date

This rule ensures that the End Date is after the Start Date.

Validation Rule Detail

Claim Period Required When Funding Source is Home Care Package

Ensures that the Claim Period is provided when the Funding Source is Home Care Package.

Validation Rule Detail

Automation

Flows

The list below outlines the Flows applied to the Funding Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Plan Date Change Email Notification

This flow is designed to send an email notification when the start or end date of a Funding record changes.

Flow Detail

Flow Summary

  • This flow sends an email notification when the start or end date of a funding record changes.

  • It determines the recipient based on the email settings.

  • Sends the email using a specified template.

  • Triggers on the update of a funding record.

  • Runs asynchronously after the record is saved.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow is triggered upon the update of a funding record.

    • The flow runs asynchronously after the record is saved.

    • Proceeds to a fake assignment to fix a packaging issue.

  2. Fake Assignment (Assignment):

    • This step exists to ensure the flow runs properly due to a packaging issue.

    • Proceeds to the decision step to check if the email template in the email setting is null.

  3. Is Template in Email Setting Null? (Decision):

    • Checks if the templateFromEmailSetting is null.

    • No: If the template is not null, proceeds to the decision step to determine the email recipient.

    • Yes: Ends the flow.

  4. To whom should this message be delivered? (Decision):

    • Checks the recipient from the email setting and determines who should receive the email.

    • Recipient In Email Setting Equals Current Participant Owner: Assigns the participant owner's ID to UserIdToSendEmail and proceeds to send the email.

    • Recipient In Email Setting Equals User And User Id In Email Setting Is Not Null: Assigns the user ID from the email setting to UserIdToSendEmail and proceeds to send the email.

  5. Set Plan Participant Owner Id (Assignment):

    • Assigns the participant owner's ID to UserIdToSendEmail.

    • Proceeds to send the email.

  6. Set User Id (Assignment):

    • Assigns the user ID from the email setting to UserIdToSendEmail.

    • Proceeds to send the email.

  7. Send Email (Apex Action):

    • Calls the SendEmailInvocable Apex action to send the email.

    • Passes the email template, from email address, and recipient ID as input parameters.

    • Ends the flow.

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Funding Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Funding Record Adjust Recurring Invoices

This trigger is designed to manage the adjustment of recurring invoices for plans in Maica.

Detail
Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the FundingAdjustRecurringInvoices_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the adjustment process for recurring invoices.

  • Trigger Conditions:

    • When a new funding record (maica_cc__Funding__c) is created.

    • When an existing funding record is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a plan record is created or updated, the trigger is initialised. The FundingAdjustRecurringInvoices_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the FundingAdjustRecurringInvoices_MDTM class.

    • The class methods perform the following steps:

      • Validation: The funding record data is validated to ensure it is complete and accurate.

      • Adjustment: Recurring invoices are adjusted based on changes to the funding record details, such as modifications to the services or billing frequency.

      • Update: The funding record is updated with the newly adjusted invoice data.

Trigger Outcome:

Once executed, the trigger ensures that recurring invoices for funding records are adjusted correctly, according to the logic specified in the handler class. This helps maintain accurate invoice data for funding records.

Xero Integration

Learn how to Integrate with Xero within Maica

How do I integrate with Xero within Maica?

To learn how to configure the Xero integration in Maica, please follow the steps detailed below.

Please note that whilst completing the integration within Maica, there are further pointers and steps to assist you. This article breaks these steps down further and into more detail, hence the step numbers seen here and within Maica may vary.

To begin configuring your Xero Integration, go to the Maica Settings tab in the Menu bar. When there, select the Xero Management tab to see the following.

Here, we can see the and sections. To complete the Xero Integration, we must first set up both of these areas.

Before proceeding, make sure that the Xero Management toggle in the top right corner of your interface is set to Enabled, as shown below.

Active Connections

1. Begin Adding a New Xero Connection

The first section to complete is the Active Connections section. You can now begin to do so by adding a new Xero Connection by simply clicking the + Add New Xero Connection button within the Active Connections section, as shown below.

Once clicked, the following Xero OAuth Connection Setup pop-up will be displayed.

For privacy reasons, the Company or Application URL and Redirect URI have been obscured; however, they will be visible and pre-populated in your organisation.

2. Create a custom Web App

Using the links above, you can now create a custom Xero Web App. To do so, follow the link shown in the above image (or here: ). Once on the link, you will be presented with the following screen:

Here, you can add a Custom Name for you App, and then copy and paste the Company or Application URL and Redirect URI from Maica into the related input fields on Xero. Once done, check the Terms & Conditions box and click Create App.

Make sure your Integration Type is set to Web App. It should be selected by default.

3. Import Web App Identification Codes

Once you have created your Web App, head to the Configuration tab on the left hand side of Xero interface. There, you will see the following:

Click Generate a secret, and then copy both the Client ID and Client Secret back into the relevant fields within Maica. These fields are shown in Xero OAuth Connection Window screenshot in Step 1 of this article.

4. Confirm Redirect URI configuration

Before proceeding any further, confirm the Redirect URI shown in Maica matches that of the Redirect URI on the Configuration page within Xero (the above page). If they do, it has been configured correctly and you can proceed to the next step, if not, copy the Redirect URI from Maica and paste it into the field in Xero.

Once you have completed Steps 1, 2 and 3, click the Save button in the bottom right hand corner of the interface. This will trigger the creation of a Manage Xero Permission Set and create Named Credential Records required to finish the remaining set up steps of the Integration. Once saved, the Xero OAuth Connection Setup module on Maica will dynamically update, displaying the final remaining stages. Simply reopen it after saving to view these steps.

5. Actions to the Named Credential Record

As mentioned above, when creating a connection with Xero, Maica will create an associated Credential Record.

To learn about Credential Records in Salesforce, click .

Two actions are required on the Credential Record, these include:

  1. Enable for Callouts toggle = TRUE

  2. maica_cc to be added as a value to the Allowed Namespaces for Callouts field

To complete the above actions, first click the hyperlink to the Named Credential record in the Xero OAuth Connection Setup pop-up.

This will open up the Named Credential record where the specified actions can be completed, as shown below.

Note, The Created By Namespace field shows which managed package a component belongs to. This field is automatically populated by Salesforce and reflects Maica’s managed package namespace (maica_cc). It does not require any action.

Once done, click Save and move onto the next step.

6. Assign Users to the Created Permission Set

As also mentioned above, when creating a connection with Xero, Maica creates a Permission Set. Maica will automatically assign it to the current user, however you can assign all necessary users you desire to access the Xero Connection.

To begin, click the hyperlink to the Permission Set in the Xero OAuth Connection Setup pop-up, as shown below.

This will open up the Permission Set. Once open, click the Manage Assignments button in the menu in order to add additional users to the Set, as shown below.

Then, click the Add Assignments button in the top right hand corner of your interface, and select the checkbox for all Users you wish to assign the Permission Set to. Once done, click Next.

After clicking the Next button, Maica will take you to a summary screen of your selected Users where you can set an expiration option if desired. This allows for the ability to set a date in which the Permission to the specified Users will expire, as shown below.

By default, Permission Set assignments never expire.

To finalise your assignments, click the Assign button in the bottom right hand corner of your interface. Once done, an Assignment Summary page will show with a Success Status by each Assigned User.

7. Authenticate

Once completed, you can click the Authenticate button to finalise the Connection.

If Step 5 or Step 6 are not available in the Xero OAuth Connection Setup, you may need Authenticate prior to completing them. If so, simply navigate back to the Xero Management Settings and complete these steps after Authenticating. Do not Authenticate again in this instance, once the steps are done, simply close the window.

Webhooks

1. Add a Notifications Endpoint (Site)

The second section to complete is the Webhooks section. You can now begin to do so by first populating the Site field with your configured Site.

To learn how to configure a Site, click .

Please make sure the associated Guest User of the selected Site has Handle Xero Notifications permission set assigned.

2. Link to Xero

Once you have selected your Site, Maica will generate a URL that will be used to connect back with Xero. Copy the URL from Maica and open your previously created Xero Web App. On the side menu bar of the Web App, navigate to the Webhooks section and paste the URL in the Delivery URL field, as shown below.

Maica is only connected to the Invoices webhook, so ensure that this is the only option ticked from the Notify this app about changes to options.

3. Return Webhooks Key to Maica

Finally, from Xero, copy the Webhooks Key shown under the the Delivery URL and paste back into the Webhooks Key field in Maica, as shown below:

Test the Status in Xero to ensure that the process has been completed and is configured properly, then click Save within Maica to begin receiving Invoice Notifications.

Once you have finished setting up the Connection and Webhook, it is essential that you configure your in order to facilitate the integration. The integration will fail if the associated are not also configured. Please see the linked article to learn how to do this.

How do I removed my Xero Connection and establish a new one?

In order to establish a completely new Xero connection within Maica, you first must remove the following:

  1. The Named Credential

  2. The External Credential

  3. The Xero Authentication Provider record

To do so, re click the + Add New Xero Connection button in the Active Connections section, and follow the hyperlinks within Maica, as shown below.

When you click on each link, the corresponding record will open. Simply delete the record and repeat the process for all three before attempting to establish a Xero new connection.

Scheduled Jobs

This article provides an overview of the scheduled jobs in Maica

What are Scheduled Jobs?

Scheduled jobs in Salesforce are automated processes that run to execute background tasks such as data updates, record processing, and system maintenance. These jobs help reduce manual workload by handling repetitive operations, ensuring that key business processes continue to function without user intervention.

What are the Scheduled Jobs in Maica?

In Maica, scheduled jobs automate system processes. These jobs ensure data integrity, improve operational efficiency, and help keep the system running smoothly.

Below are all the Scheduled Jobs within Maica and their descriptions:

Create Invoice Line Items

Job Details

Purpose:

This job executes the Billing Flow and automates the creation of Invoice Line Items for Delivery Activities marked for billing.

Description:

Retrieves Delivery Activity record WHERE:

  • Billing_Status__c = 'Requested'

  • Invoice_Line_Item__c = NULL

and then disables the InvoiceLineRollupExpenditure_MDTM Trigger Handler on the Agreement Item object that calculates rollup fields related to Invoice Line Items.

It does so to avoid UNABLE_TO_LOCK_ROW system errors.

Then, the job will execute the Billing Flow selected in the that creates Invoice Line Items related to the Delivery Activity. At the end of the Scheduled Job, it updates relevant Agreement Items to trigger the rollup calculation logic.

Manage Recurring Shifts

Job Details

Purpose:

This job automates the scheduling of recurring Shifts. It ensures that Master Shifts are replicated according to set rules while avoiding conflicts with completed or cancelled shifts. The job also applies availability checks if validation settings are enabled, ensuring that only available Resources are assigned.

Description:

Retrieves Schedule records WHERE:

  • Under_Evaluation__c = TRUE

  • Status__c = 'Approved'

  • Master_Appointment__r.Status__c != 'Cancelled'

  • Master_Appointment__r.RecordType != 'Shift'

For each Schedule Record, the Job will determine the anchor date, which can either be the last Original Schedule Start, or, Schedule Start. The anchor date cannot be prior to today. Once specified, the Job creates Scheduled Shifts which are clones of Master Shifts with related Delivery Activities and Appointment Resources up until the Horizon determined in the . It is important to note that the Job does not fill up the dates where there is a Shift with a Completed or Cancelled status on a date within the Schedule. Additionally, the Status for each Record is being determined via the Settings. Maica will default the Status to Scheduled, but you can change this to suit your preference. If the Enforce Availability for Appointment Setting under is enabled, the Job will perform the same Validation as a user would creating the Appointment manually, hence, if Resources are Unavailable they will not be copied across to the newly created Shifts. Note: The Original Schedule Start field stores the value of the Schedule Start field when it is changed for the first time after it has been created.

Manage Recurring Appointments

Job Details

Purpose:

This job automates the scheduling of recurring Appointments. It ensures that Master Appointments are replicated according to set rules while avoiding conflicts with completed or cancelled shifts. The job also applies availability checks if validation settings are enabled, ensuring that only available Resources are assigned.

Description:

Retrieves Schedule records WHERE:

  • Under_Evaluation__c = TRUE

  • Status__c = 'Approved'

  • Master_Appointment__r.Status__c != 'Cancelled'

  • Master_Appointment__r.RecordType != 'Appointment'

For each Schedule Record, the Job will determine the anchor date, which can either be the last Original Schedule Start, or, Schedule Start. The anchor date cannot be prior to today. Once specified, the Job creates Scheduled Appointments which are clones of Master Appointments with related Delivery Activities and Appointment Resources up until the Horizon determined in the . It is important to note that the Job does not fill up the dates where there is an Appointment with a Completed or Cancelled status on a date within the Schedule. Additionally, the Status for each Record is being determined via the Settings. Maica will default the Status to Scheduled, but you can change this to suit your preference. If the Enforce Availability for Appointment Setting under is enabled, the Job will perform the same Validation as a user would creating the Appointment manually, hence, if Resources are Unavailable they will not be copied across to the newly created Appointments. Note: The Original Schedule Start field stores the value of the Schedule Start field when it is changed for the first time after it has been created.

Manage Recurring Unavailabilities

Job Details

Purpose:

This job automates the scheduling of recurring Unavailabilities by cloning Master Unavailability. It ensures that new unavailability records are created based on the anchor date while adhering to validation settings. The job also prevents creation of back-dated Unavailability records and maintains scheduling accuracy by setting default statuses according to setting configuration.

Description:

Retrieves Unavailability records to clone for Schedule record WHERE:

  • Under_Evaluation__c = TRUE

  • Status__c = 'Approved'

  • Master_Unavailability__c != NULL

For each Schedule Record, the Job will determine the anchor date (either the last Original Unavailable From, or, Unavailable From). The anchor date cannot be prior to today. Once the anchor date is specified, the Job creates Unavailabilities which are clones of Master Unavailability up until the Horizon determined in the . The Status for each Record is being determined via the Settings. Maica will default the Status to Submitted, but you can change this to suit your preference. Note: The Original Unavailable From field stores the value of the Unavailable From field when it is changed for the first time after it has been created.

Creates Renewals

Job Details

Purpose:

When the criteria below is met, the job will close Service Agreement and related Agreement Item records to create a new Service Agreement for Participants. That Start and End Date will be populated based on the values saved in the Renewal Management Settings.

Description:

Retrieves Service Agreement records to clone where:

  • Auto_Renewal__c = TRUE

  • End_Date__c >= :(TODAY - Days_Prior_Agreement_End_Date__c)

  • Clones Service Agreements and Agreement Items

PRODA Device Keys Expiration Management

Job Details

Description:

Refreshes PRODA device keys if they are less than two days away from their expiry date.

PRODA Device Keys Activation Reminder

Job Details

Description:

Sends reminder email when 30 days before expire and every day 7 days before expire

Manage Funding Item Include Attribute

Job Details

Description:

This job ensures that the Include checkbox on Funding Item records is correctly maintained, determining whether each item should be included in rollup calculations to the parent Funding record.

Check your Salesforce Hosting

Learn about how to check that your Salesforce instance is hosted in Australia.

Maica connects natively to the NDIS APis as well as hosts sensitive Participant information, so it is a requirement to host your underlying Salesforce instance in Australia. This article shows you how to check if your Salesforce instance is hosted in Australia.

Should you find that your Salesforce instance is not hosted in Australia, you can to assist with the migration of this.

To check your hosting for Saleforce, follow the steps outlined below:

  1. Log into your Salesforce instance

  2. Go to Setup

  3. Type Company Information

  4. Check the Instance value

  5. Go to

  6. Copy & Paste the Instance value to see where your instance is located

Booking Item

The Booking Item object in Maica represents funding within an active Service Booking for a given NDIS Category.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Booking Item object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Booking Item Schema.

Billing Management Settings
General Settings
Service Management
Validation Management
General Settings
Service Management
Validation Management
General Settings
Validation Management
Active Connections
Webhooks
developer.xero.com
here
here
Support Items
Support Items
Funding Item Schema
Payment Request Schema
Resource Participant Schema
Service Agreement Statement Schema

Rule Name

VAL_FUNDING_0001

Error Message

VAL_0001: The End Date must be after the Start Date.

Error Location

End Date

Error Condition Formula
maica_cc__Start_Date__c  > maica_cc__End_Date__c

Rule Name

VAL_FUNDING_0002

Error Message

VAL_0002: Please ensure that the Claim Period is provided when the Funding Source is HCP.

Error Location

Top of Page

Error Condition Formula
AND(
ISPICKVAL(maica_cc__Funding_Source__c, "Home Care Package"),
ISPICKVAL(maica_cc__Claim_Period__c, "")
)

Flow Label

Maica - Funding Date Change Email Notification Flow

API Name

maica__Funding_Date_Change_Email_Notification_Flow

Type

Autolaunched Flow

Load Order

1

Label

FundingAdjustRecurringInvoices_MDTM

here
contact us
https://availability.salesforce.com/find-my-instance/
here

Service Agreement Leave

This object represents a period where the Service Agreement will be placed in an On Leave Status.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Service Agreement Leave object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Service Agreement Leave Schema.

Automation

Flows

The list below outlines the Flows applied to the Service Agreement Leave Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Scheduled Updates

This scheduled flow handles updates to Service Agreements and Consecutive Leave Counter based on Service Agreement Leave Status updates.

Flow Detail

Flow Label

Maica - Service Agreement Leave - Scheduled Updates

API Name

maica__Maica_Service_Agreement_Leave_Scheduled_Updates

Type

Autolaunched Flow

Flow Summary

This flow ensures that service agreements and their consecutive leave counters are accurately updated based on the leave status.

  • Scheduled to run daily.

  • Evaluates the leave status and updates the service agreement accordingly.

  • Handles alternate active leave records and updates leave completion status.

Flow Description
  1. Start (Scheduled Flow):

    • The flow runs daily at midnight.

    • Filters records where Leave_Complete__c is false and Leave_Status__c is not 'Pending'.

  2. Decision Leave Status (Decision):

    • Determines the leave status:

      • If Leave Status is 'Active', it assigns service agreement values and updates the service agreement.

      • If Leave Status is 'Complete', it checks for alternate active leave records.

  3. Assign Service Agreement Values (Assignment):

    • Sets On_Leave__c to true.

    • Increments the Consecutive_Leave_Days__c by 1.

    • Sets the Service Agreement Id.

  4. Update Service Agreement (Record Update):

    • Updates the service agreement with the new values assigned.

  5. Get Alternate Active Leave Records (Get Records):

    • Retrieves any alternate active leave records related to the same service agreement.

  6. Decision Alternate Active Leave (Decision):

    • Determines if there are alternate active leave records:

      • If there are, it assigns variable values for the leave status and updates the service agreement leave.

      • If there are not, it assigns variable values to mark the leave as complete and updates the service agreement.

  7. Assign Variable Values (Assignment):

    • Sets On_Leave__c to false.

    • Marks Leave_Complete__c as true.

    • Resets Consecutive_Leave_Days__c to 0.

    • Sets the Service Agreement Id.

  8. Update Service Agreement (Record Update):

    • Updates the service agreement with the new values assigned.

  9. Assign Variable Values for Alternate Leave (Assignment):

    • Marks Leave_Complete__c as true.

  10. Update Service Agreement Leave (Record Update):

    • Updates the service agreement leave record.

Triggered Updates

This record-triggered flow handles updates to Service Agreements and the Consecutive Leave Counter when the Service Agreement Leave status is updated.

Flow Detail

Flow Label

Maica - Service Agreement Leave - Triggered Updates

API Name

maica__Maica_Service_Agreement_Leave_Triggered_Updates

Type

Autolaunched Flow

Flow Summary

This flow ensures that service agreements and their consecutive leave counters are accurately updated based on the leave status.

  • Starts on the creation or update of a Service Agreement Leave record.

  • Evaluates the leave status and updates the service agreement accordingly.

  • Handles alternate active leave records and updates leave completion status.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow begins when a Service Agreement Leave record is created or updated.

    • It is triggered after the record is saved.

    • The flow is triggered by changes to Start Date, End Date, or when the record is newly created.

  2. Decision Leave Status (Decision):

    • Determines the leave status:

      • If Leave Status is 'Active', it checks the Leave Start Date.

      • If Leave Status is 'Complete', it checks for alternate active leave records.

  3. Decision Leave Start Date (Decision):

    • Checks if the Leave Start Date is equal to the current date:

      • If yes, it assigns service agreement values and updates the service agreement.

      • If the Leave Start Date is before the current date, it assigns service agreement values using a calculation and updates the service agreement.

  4. Assign Service Agreement Values (Assignment):

    • Sets On_Leave__c to true.

    • Increments the Consecutive_Leave_Days__c by 1 or calculates it based on the current date.

    • Sets the Service Agreement Id.

  5. Update Service Agreement (Record Update):

    • Updates the service agreement with the new values assigned.

  6. Get Alternate Active Leave Records (Get Records):

    • Retrieves any alternate active leave records related to the same service agreement.

  7. Decision Alternate Active Leave (Decision):

    • Determines if there are alternate active leave records:

      • If there are, it assigns variable values for the leave status and updates the service agreement leave.

      • If there are not, it assigns variable values to mark the leave as complete and updates the service agreement.

  8. Assign Variable Values (Assignment):

    • Sets On_Leave__c to false.

    • Marks Leave_Complete__c as true.

    • Resets Consecutive_Leave_Days__c to 0.

    • Sets the Service Agreement Id.

  9. Update Service Agreement Leave (Record Update):

    • Updates the service agreement leave record.

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Service Agreement Leave Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Service Agreement Leave Overlap

This trigger is designed to manage the overlap of leave periods in service agreements within Maica.

Detail

Load Order

1

Label

ServiceAgreementLeaveOverlap_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the ServiceAgreementLeaveOverlap_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the overlap check process for service agreement leave periods.

  • Trigger Conditions:

    • When a new service agreement leave (maica__Service_Agreement_Leave__c) is created.

    • When an existing service agreement leave is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a service agreement leave record is created or updated, the trigger is initialised. The ServiceAgreementLeaveOverlap_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ServiceAgreementLeaveOverlap_MDTM class.

    • The class methods perform the following steps:

      • Validation: The leave period data is validated to ensure it is complete and accurate.

      • Overlap Check: Existing leave periods in the service agreement are checked for overlaps with the new or updated leave period.

      • Update: If an overlap is detected, the service agreement leave record is updated with overlap information to indicate the conflict.

Trigger Outcome:

Once executed, the trigger ensures that each service agreement leave period is checked for overlaps correctly, according to the logic specified in the handler class. This helps maintain accurate leave period data and prevents conflicts in service agreements.

Service Agreement Leave Appointments

This trigger is designed to manage the appointments related to leave periods in service agreements within Maica.

Detail

Load Order

1

Label

ServiceAgreementLeaveAppointments_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the ServiceAgreementLeaveAppointments_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the appointment management process for service agreement leave periods.

  • Trigger Conditions:

    • When a new service agreement leave (maica__Service_Agreement_Leave__c) is created.

    • When an existing service agreement leave is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a service agreement leave record is created or updated, the trigger is initialised. The ServiceAgreementLeaveAppointments_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ServiceAgreementLeaveAppointments_MDTM class.

    • The class methods perform the following steps:

      • Validation: The leave period data is validated to ensure it is complete and accurate.

      • Appointment Management: Based on the leave period, related appointments are either created or updated to ensure they reflect the leave period accurately.

      • Update: The service agreement leave record is updated with the newly managed appointment data if necessary.

Trigger Outcome:

Once executed, the trigger ensures that each service agreement leave period has its related appointments managed correctly, according to the logic specified in the handler class. This helps maintain accurate appointment data and ensures that all appointments are in sync with leave periods.

Contact

The Contact object in Maica is used to manage the details of individuals associated with service delivery, including clients, guardians, and carers.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Contact object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Contact Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Contact Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

NDIS Number Must Be 9 Digits

Ensures that the NDIS Number is 9 digits.

Validation Rule Detail

Rule Name

VAL_CONTACT_0001

Error Message

VAL_0001: If provided, the NDIS Number must be 9 characters in length.

Error Location

Top of Page

Error Condition Formula
IF (
NOT(ISBLANK(maica_cc__NDIS_Number__c)), OR(LEN(maica_cc__NDIS_Number__c) <>9, NOT(
ISNUMBER(maica_cc__NDIS_Number__c))), false
)

Automation

Flows

The list below outlines the Flows applied to the Contact Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Participant Geocoding

This Salesforce Autolaunched Flow is designed to geocode addresses for participants, updating their latitude and longitude based on the provided address information.

Flow Detail

Flow Label

Maica - Participant Geocoding

API Name

maica__Maica_Participant_Geocoding

Type

Autolaunched Flow

Flow Summary

This flow facilitates the geocoding of participant addresses by:

  • Detecting changes to participant records and ensuring address fields are populated.

  • Calling an Apex action to geocode the address.

  • Updating the participant record with the geocoded latitude and longitude.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow is initiated upon the creation or update of a participant record.

    • Checks if the latitude and longitude are set to 0.0 and ensures that the address fields (MailingCity, MailingPostalCode, MailingStreet, and MailingState) are not null.

    • Proceeds to geocode the address asynchronously after the record is saved.

  2. Geocode the Address (Apex Action):

    • Calls the GeocodeAddressInvocableProc Apex action to geocode the address.

    • Passes the address fields and the record ID as input parameters.

    • Captures the latitude and longitude from the geocoding result.

    • Proceeds to the Error decision.

  3. Error? (Decision):

    • Checks if there is an error message from the geocoding process.

    • If no error, proceeds to update the participant record with the geocoded latitude and longitude.

    • If an error is detected, the flow ends.

  4. Update Participant (Update Records):

    • Updates the participant record with the latitude and longitude from the geocoding result.

    • Ends the flow.

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Contact Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Participant Geocoding

This trigger is designed to manage the geocoding of participants in Maica.

Detail

Load Order

1

Label

ParticipantGeocode_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the ParticipantGeocode_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the geocoding process for participants.

  • Trigger Conditions:

    • When a new participant (Contact) is created.

    • When an existing participant is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a participant record is created or updated, the trigger is initialised. The ParticipantGeocode_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ParticipantGeocode_MDTM class.

    • The class methods perform the following steps:

      • Validation: The participant's address data is validated to ensure it is complete and accurate.

      • Geocoding: The validated address data is converted into geographical coordinates using geocoding services.

      • Update: The participant record is updated with the newly obtained geographical coordinates.

Trigger Outcome:

Once executed, the trigger ensures that each participant is geocoded correctly, based on the logic defined in the handler class. This helps maintain accurate geographical data for participants.

Contact Update Connections Type

This trigger is designed to manage the updating of connection types for contacts in Maica.

Detail

Load Order

2

Label

ContactUpdateConnectionsType_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the ContactUpdateConnectionsType_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the updating process for connection types.

  • Trigger Conditions:

    • When a new contact (Contact) is created.

    • When an existing contact is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a contact record is created or updated, the trigger is initialised. The ContactUpdateConnectionsType_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ContactUpdateConnectionsType_MDTM class.

    • The class methods perform the following steps:

      • Validation: The contact data is validated to ensure it is complete and accurate.

      • Update: The connection type is updated based on predefined criteria such as contact status or type.

      • Notification: Relevant stakeholders are notified if necessary, ensuring that all parties are aware of the updates.

Trigger Outcome:

Once executed, the trigger ensures that each contact's connection type is updated correctly, based on the logic defined in the handler class. This helps maintain accurate data and operational efficiency.

NDIS Notifications

Learn how to Integrate with Stripe within Maica

What are NDIS Notifications?

NDIS Notifications are data updates made available through webhooks for integrated systems when certain events occur within the NDIS. These notifications provide information on changes within the NDIS through webhooks, which Maica uses to capture and display event data. This data is then displayed or updated within the application as needed.

It is important to note that NDIS notifications via webhooks are not real-time alerts sent to users in the traditional sense. Instead, they function as data updates that are made available through webhooks when specific events occur on the NDIS side. These notifications simply provide information that Maica can retrieve and display to users, but they don't actively notify users on their own.

To further understand NDIS Notifications, please refer to the definitions from the NDIS:

Term
Definition

NDIS Notifications

Digital Partners (Maica) can receive notifications for events they have subscribed to, by leveraging Webhooks.

Webhook

A webhook (also called a web callback or HTTP push API), is a lightweight API that powers one-way data sharing triggered by events. Unlike typical API's where you would need to poll for data in order to get updates in real-time, a webhook delivers data to your application as the event happens, meaning you get the data immediately.

Events

Specific actions or changes within the NDIS system that trigger data updates through webhooks. These events signify key occurrences related to a participant's plan, funding, or service interactions that integrated systems need to be aware of. Examples of events include a plan modification, a funding allocation update, or a change in the status of an invoice. When such an event occurs, the NDIS generates a webhook with the relevant data, allowing Maica to capture and reflect this information for users.

Please see the table below to see which NDIS Events Maica supports and handles.

Events

The following table outlines the Events Maica supports.

Each Event is linked to an associated Flow Description. This explains in more detail how the Event is handled within Maica.

Name
Code
Description

New Service Booking created

SB_NEW

The notification for this event will be triggered when a new service booking is created:

  • By a Staff member using the staff portal

  • By a Participant using the myplace participant portal

  • By a Provider using the myplace provider portal

  • Via API

SB End Date updated

SB_END_DATE_UPDATED

The notification for this event will be triggered when the end date of a service booking is updated:

  • By a Staff member using the staff portal

  • By a Participant using the myplace participant portal

  • By a Provider using the myplace provider portal

  • By a Digital Partner using Provider API's PATCH

  • Due to a plans' end date being updated as a result of an unscheduled plan review, participant access being revoked or participant access being ceased (due to death).

Service Booking Budget Updated

SB_BUDGET_UPDATED

The notification for this event will be triggered when the quantity and/or allocated amount of one or more supports within a service booking is updated:

  • By a Staff member using the staff portal

  • By a Participant using the participant portal

  • By a Provider using the myplace provider portal

  • Via API

Service Booking deleted

SB_DELETED

The notification for this event will be triggered when a service booking is deleted

  • By a Participant using the myplace participant portal

  • By a Provider using the myplace provider portal

  • By a Provider using the Provider API's DELETE /{service_booking_id} operation

Remittance Advise is generated

REMIT_ADV_GENERATED

The notification for this event will be triggered overnight and the JSON payload available in your chosen webhook, when the remittance advice is ready, for payment claims that have been processed and paid, the day before. See sample JSON payload below:

Please note that this notification does not currently work in the Test Vendor environment and therefore cannot be used for testing.

Budget Updated

BUDGET_UPDATED

This notification will allow Plan Managers and Support Coordinators to be notified when SAP participant's budget is changed given that consent is provided. The notification for this event will be triggered and sent to the Plan Manager or Support Coordinator when a participant's budget is updated, either via APIs or via a Staff Member using the Staff Portal, given that the provider has consent/authority with the related participant. The notification will be triggered for the following scenarios:

  • A participant plan extension

  • Service Booking creation, update, or deletion.

  • Service booking on quotation approved.

  • Update on Participant's Active Plan Budget.

    • Spent Amount

    • Remaining Amount (claim status is pending payment, or payment cancellation)

Plan End Date is updated

PLAN_END_DT_UPDATED

The notification of this event will be triggered when the plan end date of a participant's current active plan is updated

  • Due to an unscheduled plan review

  • Due to the auto extension of plan

  • Due to the participant's access ceasing (due to death for instance)

PACE Budget Updated

BUDGET_UPDATED

This notification will allow Plan Managers and Support Coordinator to be notified when a PACE participant's budget is updated.

The notification for this event will be triggered sent to the Plan Manager or Support Coordinator when a participant's budget is updated via APIs or a Staff Member using the Staff Portal given that provider has consent/authority with the related participant.

PACE New Plan Created

PLAN_APPROVED

This notification will allow Plan Managers or Support Coordinator to be notified when a participant's new plan is created.

The notification for this event will be triggered and sent to the Plan Manager or Support Coordinator when there is a new plan approval given that the provider has consent/authority to view plan details with the related participant.

PACE Relationship Created

RLTN_CREATED

For PACE participant the notification for this event will be triggered when:

  • My Provider Relationship is created between participant and provider in PACE.

  • Plan Manager Relationship is created between participant and provider in PACE.

  • Recovery Coach Relationship is created between participant and provider in PACE.

  • Support Coordinator Relationship is created between participant and provider in PACE.

PACE Relationship End Date Update

RLTN_END_DATE_UPDATE

For PACE participant the notification for this event will be triggered when:

  • My Provider Relationship end date is updated in PACE.

  • Plan Manager Relationship end date is updated in PACE.

  • Recovery Coach Relationship end date is updated in PACE.

  • Support Coordinator Relationship end date is updated in PACE.

How do set up NDIS Notifications?

In order to set up the NDIS Notifications within your Maica instance, please follow the following steps:

  1. Create a Salesforce Site under the name NDIS Notifications.

To learn how to Create a Site, please click here.

  1. Assign the Maica - Handle NDIS Notifications permission set to the Site Guest User.

This Permission Set grants access to Maica objects that will be updated based on the NDIS event payload.

Ensure the Site Guest User is assigned the proper timezone. This is important as Salesforce sets it to GMT by default.

  1. Navigate to Maica Settings -> NDIS Notifications

  2. Find and choose the created Site in the Notifications Endpoint (Site) , as shown below:

  1. Finally, select the Subscribe All button

Please note, Maica’s subscription to NDIS events is secured with a private key generated on the Salesforce side, ensuring that only the authorised NDIS endpoint can transmit data to Maica’s Salesforce public site. Each notification payload is validated to confirm it is signed with the private key, maintaining the integrity and security of the data exchange.

Billing Invoice Generation

Learn about Maica's Billing engine and Invoice Generation logic.

Overview

The following article details Maica's Invoice Generation Logic. It provides further insight in understanding how the Billing lifecycle works within Maica.

The Billing Engine in Maica is powered by the Maica - Invoice Flow. This flow is further detailed below.

Maica's Invoice Flow

This flow is designed to generate an Invoice and Invoice Line Items for Delivery Activities within Maica. The flow retrieves the necessary data from Delivery Activities, Service Agreements, and associated Products, calculates costs based on predefined caps (e.g., travel caps), and creates Invoice Line Items.

If any part of the process fails, the flow handles the errors by formatting and logging fault messages. Error handling is included throughout the flow to capture and log any faults that occur during processing.

Below are all the stages and logic of the Maica - Invoice Flow.


  1. Start (Auto-Launched Flow):

    • Description: The flow is automatically triggered and begins by retrieving the details of a Delivery Activity.

  2. Get Delivery Activity (Record Lookup):

    • Description: This lookup retrieves the Delivery_Activity__c record using the provided recordId. The flow fetches this data from the database, looking for any activity matching the input recordId.

    • Next Step: The flow checks whether the activity is billable using the Should be Billed? decision.

  3. Should be Billed? (Decision):

    • Description: This decision evaluates whether the delivery activity should be billed. It checks if:

      • The Billing_Status__c is set to Requested.

      • An Invoice_Line_Item__c has not already been created for this activity.

    • Next Step: If these conditions are satisfied, the flow proceeds to retrieve cost data using Get_Cost_Data.

  4. Get Cost Data (Apex Action):

    • Description: The flow invokes the DeliveryCostCalculationInvocable Apex class, which calculates the cost of the Delivery Activity based on the Service Agreement, Price Lists, and Support Items.

    • Inputs:

      • recordId: The ID of the Delivery Activity is passed to the Apex action to identify the relevant data for the cost calculation.

    • Outputs:

      • The Apex action returns a set of key data, including:

        • agreementItem: The specific Agreement Item tied to this activity.

        • unitPrice: The calculated unit price for the Service.

        • quantity: The quantity of units to bill for.

    • Next Step: Once the cost data is retrieved, the flow looks up the Service Agreement.

  5. Get Service Agreement (Record Lookup):

    • Description: This lookup fetches the Service_Agreement__c associated with the Delivery Activity’s Agreement Item. The flow uses the agreementItem.Service_Agreement__c ID obtained from the cost data.

    • Next Step: After retrieving the Service Agreement, the flow proceeds to generate or retrieve an Invoice.

  6. Get Invoice (Apex Action):

    • Description: This Apex action (GetInvoiceInvocable) either retrieves an existing Invoice or creates a new one based on the input parameters. This step ensures that any subsequent billing actions are tied to the correct Invoice for the participant and service provider.

    • Inputs:

      • fundingType: Derived from the Service Agreement’s Funding_Type__c.

      • participantId: Fetched from the Delivery Activity’s Participant__c.

      • serviceProviderStr: The Service_Provider__c linked to the Service Agreement.

    • Outputs:

      • The result of this action is the Invoice__c record, which is stored in the flow’s invoice variable.

    • Next Step: The flow proceeds to retrieve the associated Product for the Invoice Line Item.

  7. Get Product (Record Lookup):

    • Description: This step looks up the Product2 record related to the Support Item being billed. The flow uses the Support_Item__c from the cost data’s agreementItem to identify the product.

    • Validation:

      • The lookup ensures that the Product2 record is valid for billing by checking:

        • The product exists in the database and is not null.

        • The Support_Item__c field correctly matches a product ID, ensuring the right product is billed for the Delivery Activity.

    • Next Step: Once the product is validated, the flow checks if the product is found using the Product Found? decision.

  8. Product Found? (Decision):

    • Description: This decision ensures that a valid Product2 record was retrieved in the previous step. The flow checks if:

      • The Product ID is not null (Get_Product.Id is set).

      • The Product exists in the system.

    • Next Step: If the Product is found, the flow moves to initialise the Invoice Line Item.

  9. Initalise Invoice Line Item (Assignment):

    • Description: In this step, the flow initialises the Invoice_Line_Item__c record by assigning values for several key fields, including:

      • Product__c: The ID of the retrieved Product (Get_Product.Id).

      • Invoice__c: The ID of the Invoice created or retrieved in the previous step.

      • Agreement_Item__c: The Agreement Item ID from the cost data.

      • Claim_Type__c: The claim type from the Delivery Activity.

      • Unit_Price__c: The unit price obtained from the cost calculation.

      • Quantity__c: The quantity calculated from the cost data.

      • Service_Date__c: The service date from the Delivery Activity.

      • Status__c: Set to Entered.

    • Next Step: The flow evaluates whether the travel caps need to be applied.

  10. Is Travel over the Chargeable Travel Cap? (Decision):

    • Description: This decision checks whether the Delivery Activity is non-time-based (Non_Time_Based_Activity__c) and whether the Quantity__c exceeds the TravelCapKms. This ensures that the travel charges are capped at a certain limit based on kilometres.

    • How TravelCapKms is Determined:

      • The flow checks if the Chargeable_Travel_Cap__c field from the agreementItem is greater than 0. If so, this value is used as the TravelCapKms.

      • If the agreementItem does not have a specific travel cap, the flow falls back to the system-wide travel cap.

      • If neither the agreement-specific nor system-wide caps are set, the travel cap defaults to 0, meaning no travel charges are allowed.

    • Next Step: If the quantity exceeds the travel cap, the flow moves to adjust the quantity.

  11. Set Maximum (Assignment):

    • Description: Adjusts the Quantity__c of the Invoice Line Item to fit within the allowed TravelCapKms. This step ensures that the Invoice Line Item does not exceed the allowable limit for travel-related charges.

    • The Quantity__c of the Invoice Line Item is set to the calculated value of TravelCapKms (derived from either the Service Agreement or system settings).

  12. Is Travel over the Time Travel Cap? (Decision):

    • Description: This decision checks whether the delivery activity is time-based (Time_Based_Activity__c) and whether the Quantity__c exceeds the TravelCapHours. It ensures that time-based travel charges are capped at a certain limit.

    • How TravelCapHours is Determined:

      • Similar to the TravelCapKms, the flow first checks the Time_Travel_Cap__c field in the agreementItem. If set, this value is used as the maximum allowable time-based travel.

      • If the agreementItem.Time_Travel_Cap__c is not set, the flow checks the system-wide setting.

      • If no time travel caps are specified in either the agreement or system-wide settings, the time-based travel cap defaults to 0, meaning no time-based travel charges are allowed.

  13. Set Maximum (Assignment):

    • Description: Adjusts the Quantity__c of the Invoice Line Item to fit within the allowed TravelCapHours. This prevents overcharging for time-based travel activities.

    • The Quantity__c of the Invoice Line Item is set to the calculated value of TravelCapHours, which is derived from the Service Agreement or system-wide settings.

  14. Create Invoice Line Item (Record Create):

    • Description: This step creates the Invoice_Line_Item__c record using the data assigned earlier. The flow saves the line item and links it to the relevant Invoice and Product.

  15. Update Delivery Activity (Record Update):

    • Description: The Delivery Activity is updated with the relevant details, including:

      • The Agreement_Item__c linked to the Service Agreement.

      • The Billing_Status__c, which is set to Generated, indicating that the billing process has been completed.

      • The newly created Invoice Line Item is linked to the Delivery Activity.

  16. The flow completes the process of generating the Invoice and updating the related records.


Flow Summary

This flow automates the generation of Invoices and Invoice Line Items for Delivery Activities within Maica. It ensures that invoices are accurately created based on the Service Agreements and predefined caps for travel and time-based activities. Error handling is included throughout the flow to capture and log any issues during processing.

NDIS Integration

Learn about NDIS Integration Settings in Maica

These settings determine how Maica manages the connection of your Maica instance to PRODA and the NDIS APIs.

Things to Note: NDIS Integrations

In order to achieve a successful connection between your Maica instance and the NDIS APIs, both your Organisation and Software Instance, or Device, must be registered within PRODA. As part of this process, a Device Activation Code (DAC) will be provided by PRODA during software instance registration that will be required by Maica so we can activate the device on your behalf.

Please note the following definitions:

Term
Definition

PRODA (Provider Digital Access)

A secure online authentication system used by government services, including NDIS, to verify the identity of providers and manage authorised system access.

Device

Refers to a software instance or system that connects to the NDIS API, enabling authorised digital interactions between service providers and NDIS.

Device Activation Code (DAC)

A unique code provided by PRODA when registering a software instance, required for authorising the device to access NDIS APIs on behalf of the registered organisation.

Whilst Maica has simplified this process, there are certain steps that must be completed by your Organisation, these steps are described in detail below under PRODA Device Management.

Activate PRODA Device

Prerequisite Requirements

Prior to using Maica, you need to activate your PRODA device. As mentioned above, an active PRODA device is required in order for Maica to use any of the API functions, without this, Maica cannot connect.

As a prerequisite to this step, it is assumed that you have completed the following steps:

  • Created and verified your PRODA account

  • Created and registered your B2B Device within PRODA

If you need help with the above, the NDIA published a PRODA Step-by-Step Guide, which provides instructions and screenshots to walk you through the two processes listed above.

Device Registration in PRODA

When you register the device within PRODA, please make note of the following details in order to ensure a successful connection in Maica. Please follow the instructions outlined in the official NDIA PRODA Step-by-Step Guide (see Page 20 onwards):

  • Add Service Provider (NDIS API) – Page 20

  • Assign Device Attribute – Use NAPI_PROVIDER_CATALOGUE – Page 22

  • The Device Name must be maica

  • Please make sure the Device Name is all lowercase

  • When you are provided with your Device Activation Code (DAC), store somewhere safe - you cannot get this detail once you leave this screen

For convenience, you may copy the Device Name provided below:

maica

Once the PRODA device is created, ensure the following details are captured and available:

  • Device Activation Code

  • Device Name

  • PRODA RA (Organisation ID)

These details are required to finalise the connection in the Maica Integration Settings screen.

Device Activation in Maica

Within the NDIS Integration settings, under Activate PRODA Device, you will find input boxes to populate with your information from PRODA. This includes the following:

Each of these fields is further detailed below:

You will be issued all of this information following completion of your B2B Device Registration in PRODA

  • Mode: Your PRODA environment that you wish to connect Maica to.

    • If you are using a Maica Sandbox - this should be TEST

    • If you are using your Maica Production instance - this should be LIVE

  • Your Device Activation Code: The device activation code is issued to your organisation’s authorised person during Device Registration within PRODA. The device activation code will be displayed on the browser at this point. The code is for ‘one time use’ only, with a validity period of 7 days. If the device is not activated within this time period, the authorised person is required to obtain a new activation code.

  • Device Name: The name of B2B Device. Note: it is case-sensitive.

  • PRODA RA (Organisation): This is your Registration Authority (RA) Number

Once done, click Submit Device Activation Details to finish your part of the process. This will notify the Maica team to complete the registration on our end. After successfully submitting the activation, your NDIS Integrations will let you know that your PRODA Device is Pending Activation. From here, we will complete the activation process.

Once the Device is activated and confirmed by the Maica team, this status will update to reflect that the connection is live and ready to use.

Extend PRODA Device

When you first activate a device in PRODA, they will set an expiration date. This will mark the date the device will be disabled by PRODA and can no longer be used to communicate with the APIs without being extended, or a new device created.

When your device is initially registered, Maica will store the Device Expiry Date, so we can help manage this process and ensure that you are alerted well ahead of time so you can extend the device and ensure continuity of your access to the APIs.

Failing to extend or activate a new device prior to the Device Expiry Date will result in the device being disabled by PRODA and Maica will be unable to communicate with any of the NDIS API functions.

Viewing your Device Expiry Date

After completing the device activation process, the NDIS Integration tab will display the Device Expiry Date specified by PRODA. This is prominently presented in an orange panel, as shown below:

Device Extension

After completing the device activation process, the NDIS Integration tab will display the following information:

Your Maica PRODA device can be Extended at any time in PRODA portal.

You must extend your device directly from PRODA, not through Maica.

You can extend the Device Activation at any time prior to the Device Expiry Date via PRODA. Doing this prior to the Device Expiry Date will extend the current device and ensure that you do not need to create and register a new PRODA device.

Should your PRODA device expire, you will have to create and register a new device within PRODA. An expired device cannot be extended.

Device Expiry Email Notification

As mentioned above, Maica stores the Device Expiry Date once the device is activated. In addition, we have introduced a useful daily process to check the Device Expiry Date and send an email reminder to warn you of the upcoming expiry, allowing you to extend the device and avoid any disturbance.

Found in the Maica Settings under Email Management, you can configure the following:

  • Email Template: The Salesforce Lightning Email Template you would like to send

You can utilise ours, which is named Maica PRODA Device Expiry Reminder.

  • Days Prior to Expiry: The number of days prior to the the Device Expiry Date that you would like to be notified to extend the device

  • Recipient: The user you would like to receive the email notification.

This must be an Active Salesforce user

This Setting is shown below:

Expired PRODA Device

If you fail to extend the PRODA Device via the Maica Settings before the Device Expiry Date, PRODA will disable your device and display the following message on the NDIS Integration page of Maica Settings:

In this case, as mentioned above, you will be required to create and register a new device within PRODA. An expired device cannot be extended.

Furthermore, accessing any of Maica's PRODA and API-specific functionalities while your device is expired will result in the following message.

You will be unable to complete any of these actions/processes since Maica does not send any queries to the API after the device has expired.

NDIS Connection Health Check

In order to check your connection to the NDIS API Reference Data endpoint, simply click the Check API Connectivity button, as shown below:

This is a check only and will not affect your Maica data in any way.

NDIS Notifications

This section allows you to designate the Site that will handle NDIS Notifications received via webhook.

For more information on NDIS Notifications, including setup and assigning the necessary permission set, see the NDIS Notification page.

Support Items

Learn how to configure Support Items in Maica

Please note that that NDIS Support Items, that are defined by the NDIA, will be imported into your Maica instance by Maica's Data Import Function. The following article is only about configuring custom Support Items for Home Care Packages. To learn more about importing NDIS Support Items, click here.

Please also note that the term Support Item is interchangeable in the Maica system with the term Product. The terminology is dependant on which version of Maica you use.

Similar to Support Categories, custom fields have been added to the Support Item object in Maica. These allow you to configure appropriate Support Items to represent the Home Care Package Budget, and allows them to be useable within the tool.

So, the following section explains how to configure a Support Item, the steps you need to take to ensure that you can effectively set up and manage budgets while adhering to Home Care Package requirements, and details of the key configurable fields/components within the Support Item object. Below will also detail the relationship between Support Items and Support Categories, as well as how to be relate them in Maica.

How do I configure Support Items?

If you wish to configure your own Support Items within Maica in order to set up and manage budgets correctly, please follow the steps indicated below.

1. Search for Support Items in the App Launcher

In the Salesforce App Launcher, search for Support Items and choose it to open the list view of all Support Items records in your Maica instance, as shown below.

2. Create new Support Item

Once you are viewing your Support Item, simply click the New button located in the top right hand corner of your interface to bring up the New Support Item pop-up, as shown below.

After the pop-up is displayed, you will be prompted to fill-in a number of fields.

3. Populate Support Items Fields

Each field on the New Support Item pop-up is detailed below. The key fields are described and their relationships are described in further detail:

  1. Support Item Name: This will be the name of your Support Item. You can name your Support Item anyway you wish.

  2. Support Category: This field allows you to associate your Support Item with any given Support Item.

Please note that a Support Category can hold multiple Support Items, but one Support Item can only ever be associated with one Support Category. Selecting a Support Category will also populate the Support Purpose of the Support Item automatically based on the selected Support Purpose of the associated Category.

  1. Registration Group: This field allows you to associate a Support Item with a specific Registration Group for classification.

To learn more about Registration Groups, click .

  1. Support Item Number: The unique identifier number for the support item.

  2. Support Item Type: The Support Item Type pick list is a crucial field in configuring your Support Item. It essentially defines the type of Support Item, however this is important for both building your budget, as well as Maica's fee automation and regulations on a Service Agreement. There are values within the Support Item Type pick list to support a Home Care Package, these values are described below:

    Support Item Type
    Description

    Basic Subsidies

    A Basic Subsidy for home care packages is a government-funded financial support provided to eligible individuals to help cover the costs of home care services. It is part of the Australian Government’s Home Care Package Program, aimed at assisting older adults to live independently in their own homes for as long as possible. The subsidy amount depends on the level of care required, ranging from basic support for daily tasks to higher levels of care for more complex needs.

    Care Management Fees

    Care Management Fees in home care packages refer to the costs associated with planning and coordinating the care services provided to an individual. These fees cover the management of the home care package, including creating care plans, organizing services, monitoring care quality, and ensuring that the individual’s needs are met. Care management can be provided at varying levels, depending on the complexity of the Participant's requirements.

    Package Management Fees

    Package Management Fees for home care packages are the costs related to the administration and organisation of the overall home care package. These fees cover tasks such as managing budgets, handling invoicing and compliance, maintaining records, and ensuring that the services provided meet regulatory requirements. They are necessary to ensure the smooth operation of the home care package and are separate from care management fees.

    Basic Daily Fees

    Basic Daily Fees for home care packages are optional contributions paid by the individual receiving care to help cover the costs of their home care services. The fee is set by the government and is typically a small percentage of the aged pension. It helps supplement the government subsidy and can be charged in addition to the care management and package management fees, depending on the provider.

    Income Tested Fees

    Income Tested Fees for home care packages are additional fees that some individuals may be required to pay based on their income. These fees are determined by the Australian Government and apply to those with higher incomes, contributing toward the cost of their home care services. The amount varies depending on the individual’s income level, and there are annual and lifetime caps to limit the total amount a person can be required to pay. These fees are separate from the basic subsidy and other fees associated with the home care package.

    Various Types of Supplements

    Supplements for home care packages are additional payments provided by the Australian Government to support individuals with specific care needs. These supplements are designed to address special circumstances and can be added to the basic subsidy. Common types of supplements include:

    • Dementia and Cognition Supplement: For individuals with cognitive impairments such as dementia.

    • Veterans’ Supplement: For veterans who have a related health condition.

    • Oxygen Supplement: For those requiring continuous oxygen due to medical conditions.

    • Enteral Feeding Supplement: For individuals needing tube feeding.

    • Hardship Supplement: For those facing financial difficulties in paying home care fees.

    These supplements help ensure that individuals with specialised needs receive appropriate care and support.

As mentioned, selecting the correct Support Item Type is important for Maica. They allow the system to determine when you have added the Support Item as a Planned Budget so it can correctly attribute the planned Budget Item effectively. For example, a Package Management fee is obviously going to act as a debit against the package budget and will raise a package management fee through our invoicing automation, whereas a Basic Subsidy as a plan budget line is going to be added to the budget as a credit.

  1. Funding Level: Funding Level defines what level of funding can be assigned, and therefore set the rate against the relevant items.

For example, if we select a Care Management Fee, we can select from levels 1-4 and define a price level against each Funding Level by creating different Products. A Care Management Fee for a Level 1 package will attract a certain rate, whereas a higher rate will be applied to a Level 4 package. The same applies for a Basic Subsidy.

  1. Quantity Unit of Measure: The Quantity Unit of Measure field allows you to specify the billing frequency or unit for the Support Item.

Home Care Package Support Items should all be set to a daily unit of measurement because fees and credits that are in the package budget through subsidies are always charged at a daily rate according to the rate schedule provided by the Commonwealth.

  1. Claim Type:

    • Claim Types (Available): Lists possible claim types applicable to the Support Item.

    • Claim Types (Chosen): Shows selected claim types that apply specifically to this Support Item.

The Claim Type should be set as Home Care Package. Maica has various different claim types that can be applied to particular Support Items, and to make it is important to make sure that the system is selecting the Home Care Package value that we're not pulled into any order of claims process that you might be running. If you're using in Maica, and you're administering NDIS or CHSP for example, you want to selecting Home Care Package will ensure that your Home Care Package Support Items are specifically handled by your Home Care Package claiming processes.

  1. Service Day: Specifies which days this Support Item is available for service.

  2. Service Time: Sets the available time range for the service related to this Support Item.

  3. Appointment Service: Captures what Appointment Service applies to this Support Item, including Skills and Resources.

  4. Travel Activity: Marks the Support Item as a Travel Activity which is available when manually creating Timesheet Entries and Manage Travel when creating Appointments.

  5. Timesheet Activity: Marks the Support Item as a Timesheet Activity which is available when manually creating Timesheet Entries.

  6. Display Name: The name that will be displayed throughout Maica for this Support Item.

  7. Tags: Keywords or phrases that help in categorising or searching for this Support Item throughout Maica.

Once you have populated the relevant fields, click Save to finalise your Support Item.

4. Assign a Price List

Once you have configured your Support Items, it is important to add them to an associated .

To do so, refer to the related list on the Support Item record. Simply click New, to add your Support Item as a Price List entry into a configured Price List. At this point, you can set your rate.

This is particularly important, because as we add this particular Support Item to a Service Agreement using our feature, it will pull in the rate that you have set.

Once done, your Support Item will be set up and ready to support you managing budgets of a Home Care Package Service Agreement.

Connection

In Maica, the Connection object is used to track and manage relationships and connections between individuals (Contacts), including the type or nature of the relationship.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Connection object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Connection Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Connection Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Email Address Required for Connection Related Contact When Invoice or Statement Recipient equals TRUE

This rule is to ensure that the Connection Related Contact has an Email address when Invoice Recipient and/or Statement Recipient = TRUE

Validation Rule Detail

Rule Name

VAL_CONNECTION_0001

Error Message

VAL_0001: The Related Contact must have an Email address when Invoice Recipient and/or Statement Recipient = TRUE

Error Location

Top of Page

Error Condition Formula
AND(
OR(
maica_cc__Statement_Recipient__c,
maica_cc__Invoice_Recipient__c
),
ISBLANK(maica_cc__Related_Contact__r.Email)
)

Resource

The Resource object in Maica is used to manage the details of your Service Delivery Staff, i.e. Care Workers or Coordinators.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Resource object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Resource Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Resource Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

End Date Must Not Be Before Start Date

Ensures that the End Date cannot be before the Start Date.

Validation Rule Detail

Required Resource Attributes when Resource type is Resource

This validation rule ensures key Resource attributes are populated when the Resource Type is Resource. These attributes are:

  • Employment Type

  • Weekly Hours Limit

  • Daily Hours Limit

  • Weekly Hours Minimum

Validation Rule Detail

Weekly Hours Minimum Must Be Less Than Weekly Hours Limit

Ensures that the Weekly Hours Minimum is less than the Weekly Hours Limit.

Validation Rule Detail

Related User Required when Resource Type equals Resource

Ensures the User lookup is populated when Resource Type = Resource.

Validation Rule Detail

Automation

Flows

The list below outlines the Flows applied to the Resource Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Resource Geocoding

This Salesforce Autolaunched Flow is designed to geocode addresses for resources, updating their latitude and longitude based on the provided address information.

Flow Detail

Flow Summary

This flow facilitates the geocoding of resource addresses by:

  • Detecting changes to resource records and ensuring address fields are populated.

  • Calling an Apex action to geocode the address.

  • Updating the resource record with the geocoded latitude and longitude.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow is initiated upon the creation or update of a resource record.

    • Checks if the latitude and longitude are set to 0.0 and ensures that the address fields (City, Street, State, and Postal Code) are not null.

    • Proceeds to geocode the address asynchronously after the record is saved.

  2. Geocode the Address (Apex Action):

    • Calls the GeocodeAddressInvocableProc Apex action to geocode the address.

    • Passes the address fields and the record ID as input parameters.

    • Captures the latitude and longitude from the geocoding result.

    • Proceeds to the Error decision.

  3. Error? (Decision):

    • Checks if there is an error message from the geocoding process.

    • If no error, proceeds to update the resource record with the geocoded latitude and longitude.

    • If an error is detected, the flow ends.

  4. Update Resource (Update Records):

    • Updates the resource record with the latitude and longitude from the geocoding result.

    • Ends the flow.

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Resources Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Resource Deactivation

This trigger is designed to manage the deactivation of resources in Maica.

Detail
Execution, Logic & Outcome

Trigger Execution

The trigger logic defined in the ResourceDeactivation_MDTM class is executed when the trigger conditions are met.

  • Trigger Conditions:

    • When a new resource (maica__Resource__c) is created.

    • When an existing resource is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a resource record is created or updated, the trigger is initialised. The ResourceDeactivation_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ResourceDeactivation_MDTM class.

    • The class methods perform the following steps:

      • Validation: The resource status and related data are validated to ensure they meet the criteria required for deactivation.

      • Deactivation: The deactivation process is applied based on predefined criteria such as resource status and utilisation.

      • Update: Related records are updated, and relevant stakeholders are notified if necessary.

Trigger Outcome:

Once executed, the trigger ensures that each resource is deactivated correctly, based on the logic defined in the handler class. This helps maintain data integrity and operational efficiency.

Resource Geocoding

This trigger is designed to manage the geocoding of resources in Maica.

Detail
Execution, Logic & Outcome

Trigger Execution

The trigger logic defined in the ResourceGeocode_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the geocoding process for resources.

  • Trigger Conditions:

    • When a new resource (maica__Resource__c) is created.

    • When an existing resource is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a resource record is created or updated, the trigger is initialised. The ResourceGeocode_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ResourceGeocode_MDTM class.

    • The class methods perform the following steps:

      • Validation: The resource address data is validated to ensure it is complete and accurate.

      • Geocoding: The validated address data is converted into geographical coordinates using geocoding services.

      • Update: The resource record is updated with the newly obtained geographical coordinates.

Trigger Outcome:

Once executed, the trigger ensures that each resource is geocoded correctly, based on the logic defined in the handler class. This helps maintain accurate geographical data for resources.

BPR File Import Flows

Learn about the Automation involved when Importing BPR Remittance and Results Files into Maica

What are the Data Import Flows?

As part of the , Automation is involved to ensure it's successful completion.

When using the tool, you are prompted to select a Flow Setting that essentially tells Maica which type of Data you are wanting to Import and allows the Automation to read the files correctly. It is important to understand the logic within the Automation and the altercations to the Data that will be involved when doing so. This article explains the logic behind the BPR File Import Flows in more detail.

To learn about the other Flows the Data Import Utility can handle, click .

Maica - NDIS Import - BPR Results File

This flow is designed to process the NDIS Bulk Payment Request (BPR) Results File and update the status of the Payment Request in Maica.

Flow Detail

Flow Summary

  • Processes NDIS Bulk Payment Request (BPR) Results File.

  • Updates the status of Payment Requests to Open, Successful, or Failed based on the BPR file outcomes.

  • Handles errors for Paid or missing Payment Requests.

Flow Description
  1. Start (Auto-Triggered Flow)

    • The flow starts automatically when provided with a claimReference, reason, and status.

  2. Get Payment Request (Record Lookup)

    • Looks up the Payment_Request__c record based on the following:

      • Claim_Reference_Index__c = claimReference

      • Claim_Reference_Index__c is not null.

    • If the record lookup fails, it redirects to the Handle Failure assignment.

  3. IF (Decision)

    • Checks if a Payment Request record was found:

      • Payment_Request_Found: If true, proceeds to the next decision: Payment Request Status.

      • Default Outcome: If no record is found, assigns the error message "No Payment Request" in Not Found.

  4. Payment Request Status (Decision)

    • Evaluates the status and Status__c fields to determine the next action:

      • Paid: If the current Status__c = Paid, redirects to Throw Error, setting the error message:

        • "Payment Request Status is already Paid. It was not updated as part of the import."

      • Open: If status = Open, updates the Payment Request's status to Open.

      • Successful: If status = Successful, updates the Payment Request's status to Successful and clears any error details.

      • Default Outcome: For any other status, sets the Payment Request status to Failed and assigns the failure reason to Error_Details__c .

  5. Update Payment Request (Record Update)

    • Updates the Payment_Request__c record with the new values:

      • Status__c and Error_Details__c based on the earlier decision.

  6. Throw Error (Assignment)

    • Assigns the following message to FlowFaultMessage:

      • "Payment Request Status is already Paid. It was not updated as part of the import."

  7. Handle Failure (Assignment)

    • Handles any errors in the flow by assigning $Flow.FaultMessage to FlowFaultMessage.

  8. Not Found (Assignment)

    • If no Payment Request is found, assigns the message:

      • "No Payment Request" to FlowFaultMessage.

Maica - NDIS Import - BPR Remittance File

This flow processes the NDIS Bulk Payment Request (BPR) Remittance File to handle remittance advice and update payment-related data in Maica.

Flow Detail

Flow Summary

  • Processes the NDIS BPR Remittance File for payment reconciliation.

  • Invokes an Apex action to handle remittance advice.

  • Updates relevant records with payment information (amount and date).

  • Captures errors during processing for reporting.

Flow Description
  1. Start (Auto-Triggered Flow)

    • The flow starts automatically with the following input values:

      • claimReference (NDIS Reference).

      • paidAmount (Amount Paid).

      • paidDate (Date Payment Was Made).

  2. Handle Remittance Advice (Apex Action)

    • Invokes the Apex action (as detailed below).

    • Passes the following parameters:

      • ndisReference = claimReference

      • paidAmount = paidAmount

      • paidDate = paidDate

    • Error Handling: If the Apex action fails, the flow proceeds to the Handle Failure step.

  3. Handle Failure (Assignment)

    • Captures the $Flow.FaultMessage and assigns it to FlowFaultMessage for error reporting.

NDISHandleRemittanceAdviceInvocable

The trigger logic defined in the NDISHandleRemittanceAdviceInvocable class is executed when the Data Import Flow is triggered. The class processes remittance advice data using a Claim Reference to update payment requests.

Please note, the class can also be executed when remittance advice data is received via NDIS Webhook (JSON body provided).


Trigger Conditions:

  • When a Claim Reference (ndisReference) is provided during the Data Import Flow.


Logic Explanation

1. Initialisation:

  • The trigger initialises when the input ndisReference (Claim Reference) is provided.

  • The system validates that the ndisReference is not blank.


2. Trigger Execution:

  • Validation:

    • Ensures that the ndisReference is provided.

    • Throws an error if the Claim Reference is missing.

  • Query Payment Requests:

    • Finds Payment_Request__c records where Claim_Reference_Index__c matches the provided Claim Reference.

  • Update Payment Requests:

    • Updates the following fields:

      • Paid Amount (Paid_Amount__c)

      • Paid Date (Paid_Date__c)

      • Status (Status__c → set to PAID if the Paid Amount > 0).

  • Logging:

    • If no matching payment request is found, a log entry is created for troubleshooting.


Trigger Outcome

Once executed, the trigger ensures:

  • Payment_Request__c records are updated with:

    • Paid Amount

    • Paid Date

    • Status (set to PAID if applicable).

  • Logs are created for any unmatched records.

This process ensures accurate updates to payment requests using the provided Claim Reference during the Data Import Flow.

Recurring Schedules

Learn about recurring schedules within Maica and how to manage these.

Overview

Maica support the management of recurring schedules supporting the ongoing generation of either Appointments, Shifts, or Unavailabilities. The following configuration options are available when managing Recurring Schedules.

It’s important to note that Recurring Schedules cannot be set to begin in the past. They must start either today or on a future date.

Configuration
Description
Options

Maica does not support a Fortnightly Frequency. If you wish to have a Recurring Schedule on a Fortnightly basis, please set your Frequency to Weekly, select your Schedule Day and Repeat Every 2 weeks.

Scheduled Appointment Creation Logic

Within a Recurring Schedule, Maica generates Appointments based on a Schedule Horizon and forward rolling basis. Appointment records will be created for the Schedule Horizon Date Range.

A Schedule Horizon defines the rolling time period into the future during which Maica evaluates schedules and creates corresponding Appointments. It is measured in weeks and determines how far ahead Appointments are planned and generated. You can set your desired Schedule Horizon in the Maica General Settings. For more information on setting your Schedule Horizon, click .

The Schedule Horizon Date Range is determined based on today() + Schedule Horizon (weeks)

To further understand the Appointment Creation Logic, see the below example:

Let's say you are creating a Recurring Schedule with the following inputs,

  • Schedule Horizon = 12 weeks

  • Schedule Start Date = Jan 3, 2025

  • Schedule End Date = Jun 3, 2025

  • Frequency = Daily

  • Today = Dec 3, 2024

  • Schedule Status = Approved

  • Master Appointment != null

  • Master Appointment != Cancelled

Then, when the daily batch is run, the following occurs:

  • The Schedule Horizon End Date will be calculated per below:

    • Today + 12 weeks = Feb 25, 2025

  • Maica will create Appointment records for the period between the Schedule Start Date and the Schedule Horizon End Date

    • Meaning that Appointment records will be created for the period Jan 3, 2025 to Feb 25, 2025

  • Furthermore, when the batch runs tomorrow (in this case, Dec 4, 2024), the next Appointment, or the Appointment on the Feb 26, 2025 will be created

  • And so on

This Maica logic ensures Appointment Records are created for schedules within a rolling time horizon, maintaining consistent coverage and adapting dynamically as time progresses.

When an Appointment Schedule is created the Schedule Horizon only respects 4 weeks. This is due to Salesforce limits and timeout risks during business hours. However, the overnight Batch will always respect the 12 week Schedule Horizon as per the setting.

Schedule Evaluation Date

Maica retrieves Appointment Schedule records that will be included for Appointment processing based on a Schedule Evaluation Date field. The below information defines the field and details how the logic works in practice:

Schedule Evaluation Date: Specifies the earliest date on which Maica will include the Appointment Schedule record for evaluation to determine whether Appointment records need to be created. It is calculated as the Schedule Start Date minus the Schedule Horizon (in weeks). This ensures that the system identifies and processes Appointment Schedule records within the appropriate window for generating Appointment’s on a rolling basis. The formula is shown below.

Example:

  • Given Inputs:

    • Schedule Horizon: 12 weeks

    • Schedule Start Date: 1st April 2025

    • Schedule End Date: 30th October 2025

    • Frequency: Weekly

    • Today: 4th December 2024

Formula:

Calculation:

  • Schedule Horizon = 12 weeks

    • 12 × 7 days = 84 days

  • Schedule Start Date = 1st April 2025

  • Subtract 84 days:

  • 1st April 2025 - 84 days = 7th January 2025

  • Result: Schedule Evaluation Date will be 7th January 2025.

How This Works in Practice:

  • Using the example above, on 7th January 2025, Appointment records for the 1st April to 24th June 2025 (12 weeks ahead) will be created.

  • As time progresses, the Appointment Schedule will be assessed daily and additional Appointment records will be created, maintaining the rolling 12-week horizon.

Please note, there is also an Under Evaluation field which indicates whether the Appointment Schedule is eligible for automated processing. The value is determined by a formula that evaluates whether the current date falls within the Schedule Evaluation Date and the Schedule End Date. This ensures that only relevant Appointment Schedules are included for processing. Used in both the Appointment Schedule (Recurring Appointment) and Unavailability automation logic, as show below.

Under Evaluation Formula:

All conditions inside the AND() must evaluate to TRUE for the overall formula to return TRUE.

Under Evaluation Conditions:

  • maica__Schedule_Evaluation_Date__c <= TODAY()

    • Ensures the Schedule Evaluation Date is on or before today's date.

  • TODAY() <= maica__End_Date__c

    • Ensures today's date is on or before the End Date.

  • ISPICKVAL(maica__Status__c, "Approved")

    • Checks if the picklist field maica__Status__c is set to "Approved”

Schedule Protection

Maica has logic to prevent past Scheduled Appointment being created. If the Scheduled Batch is interrupted (eg, stopped or paused) and then resumed at a later date, Maica ensures the Anchor Date is only used if the Appointment Schedule Start Date is greater than or equal to today's date. This logic prevents the creation of Appointments with dates in the past during the interrupted period.

Consider the following example:

  • Today's Date = 20th November 2024

  • An Appointment Schedule was configured to generate weekly Appointment records starting from 1st November 2024.

  • The batch process was interrupted on 10th November 2024, after creating Appointment records for 1st November and 8th November 2024.

When the batch is resumed, Maica evaluates and sets the Anchor Date to:

  • The most recent Appointment Schedule Start Date, if it is greater than or equal to today's date; or

  • Today's date, if the most recent Appointment Schedule Start Date is in the past.

By covering both scenarios, the logic ensures that the Anchor Date will always be today or a future date, never a past date.

So, if today's date is 20th November 2024, the system evaluates the most recent Appointment Schedule Start Date (8th November 2024) and determines that it is in the past. As per the logic:

  • The system ignores the 8th November 2024 date because it is before today's date.

  • Instead, it defaults the Anchor Date to 20th November 2024 (today's date), ensuring no Appointment records are created in the past.

Maica will then begin generating Appointment records starting from the next valid future date, based on the schedule's frequency.

Things to look out for: Schedules Running Old Logic After a Package Update

When a managed Apex class used in a scheduled job is updated, Salesforce does not automatically refresh the job to use the latest version of the class. Instead, it continues to execute a cached version of the old logic, which can lead to discrepancies in behaviour.

This is a Salesforce platform behaviour and applies to any scheduled job relying on an updated Apex class. To ensure the job runs with the latest logic, it needs to be manually rescheduled after an update.

Whilst this is a Salesforce platform behaviour, Maica’s development team proactively monitors and reschedules all necessary scheduled jobs after every package update. This ensures that updates are applied smoothly, and you should experience no disruption in behaviour.

If you notice any unexpected behaviour following an update, please contact the Maica team, and we’ll ensure everything is running as expected.

Service Management

Learn about Service Management Settings in Maica

These settings determine how Maica manages Appointments or Shifts and their function throughout the application. Please refer to the below table for more information on each setting:

The Service Management settings sections is divided into Appointment and Shift sections and the below tables describe both the individual as well as commonly shared settings.

Individualised Settings (for Appointments and Shifts)

Setting
Description
Applicability

Other Settings (applicable to both Appointments and Shifts)

Setting
Description

Default Status

This sets the status of the Appointment or Shift when it is first created.

Appointment and Shift

Default Schedule Status

This sets the status of the Appointment or Shift Schedule when it is first created.

Appointment and Shift

Default Type

This sets the type of the Appointment or Shift when it is first created.

Appointment and Shift

Default Duration (minutes)

This sets the duration of the Appointment or Shift when it is first created in minutes, for example 60 minutes.

Appointment and Shift

Default Resource Status

When allocating Resources to an Appointment or Shift, it is possible to set the status of this allocation to a default value, for example Approved. This setting determines what this status will be when the Appointment or Shift is first created.

Appointment and Shift

Cancellation Claim Type

When Appointments are cancelled, Maica sets the associated Delivery Activities to a cancelled status instead of deleting them. This is done via a Claim Type for any NDIS-funded Service Agreements. This setting determines which Claim Type Maica will use when cancelling Delivery Activities.

Appointment

Default Sections

An Appointment or Shift can render mutliple section, for example Location or Schedule. This is typically determined by the selected Appointment or Shift Service when selected. This setting defines what sections are set by default, in the absence on a selected Appointment or Shift Service.

Appointment and Shift

Custom Fields

Maica allows you to configure a number of custom fields (Salesforce fields you have configured outside of the core Maica package) and include these into the Appointment or Shift management experience. This setting defines what fields, including your own custom fields, will be shown when the Appointment or Shift is created/managed.

Appointment and Shift

Show Appointment Cost

Maica calculates the cost of an Appointment to the Participant based on the identified Service Agreement to indicate if the required funding is available. This setting determines, in conjunction with a permission set, if the cost of Appointment will be shown when an Appointment is either created or managed.

Appointment

Enable Files

This setting determines if Appointment or Shift files, such as photos, are available to be attached during the management of either Appointments or Shifts.

Appointment and Shift

Enforce Agreement Leave

This setting determines whether Leave records on the Service Agreement should be enforced during Appointment configuration. When enabled, Maica checks for any Leave entries associated with the selected Service Agreement. If a user attempts to schedule an Appointment that overlaps with a leave period, Maica will display an error next to the service row—indicating that the service cannot be scheduled on that day.

This check also applies during recurrence setup. If any of the recurring dates fall within a leave period defined on the Service Agreement, a warning will be shown for those dates.

Example: A Service Agreement includes a leave from 10th–12th April. If a user tries to schedule a recurring daily appointment across that period, Maica will flag 10th, 11th, and 12th April as unavailable, preventing the service from being added on those days.

Appointment

Enable Breaks

This setting enables the ability for a user to record Appointment or Shift breaks during the management of an Appointment or Shift.

Appointment and Shift

Enable Expenses

This setting enables the ability for a user to record Appointment or Shift Expenses during the management of an Appointment or Shift.

Appointment and Shift

Auto-Schedule Creator

When creating either an Appointment or a Shift, Maica is able to preset the allocated Resource to be the logged in user. The typical use case for this is when your care workers manage their own Appointments or Shifts. This setting determines if the Resource is preset when an Appointment or Shift is first created.

Appointment and Shift

Allow Participant Overlap

This allows Maica to create overlapping Appointments for Participants, in other words, a Particpant may have more than one Appointment at the same date and time.

Appointment

Allow Resource Overlap

This allows Maica to create overlapping Appointments or Shifts for Resources, in other words, a Resource may have more than one Appointment or Shift at the same date and time.

Appointment and Shift

Overlap Exclusion Status

This determines which Appointment or Shift status values are excluded from this validation, for example: if Cancelled is selected, all Appointments or Shifts with the status of Cancelled will be ignored by the validation and can therefore be overlapped regardless.

Appointment and Shift

Checklist Behaviour

This setting enables Maica to automate the addition of all relevant Checklists, based on Appointment Service, to an Appointment or Shift when it is first created.

Appointment and Shift

Checklist Permissions

This setting either presents all available Checklists to the user for adding to an Appointment/Shift or only shows the Checklists that are part of the selected Appointment Service(s).

Appointment and Shift

Daily Recurring Appointment or Shift Creation Time

This setting defines the time of day Maica will run a daily batch job to create upcoming Recurring Appointments or Shifts. It uses active schedules and generates Recurring Appointments or Shifts out to the pre-configured date range.

Appointment and Shift

Appointment Service Filters

This setting either filters the available Appointment Services based on what is funded via a Service Agreement or shows all Appointment Services regardless of funding.

Appointments

Agreement Expiry Tolerance (days)

Maica validates Appointments against a Participant's Service Agreement to ensure that sufficient funding is available to deliver the proposed services. This validation includes checking if any given Service Agreement is expired. This setting allows Maica to still consider an expired Service Agreement within a certain number of day following the expiry date, for example: if set to 30 then Maica will consider a Service Agreement to be active for up to 30 days after the expiry date.

Recurring Schedule Calculation Range

This setting controls how many recurrence entries (rows) are displayed in the Cost Breakdown section under the Recurrence tab when creating or managing an Appointment. It does not affect the number of appointments that will be created — just what’s shown on screen at once.

Appointment Service Filters

This setting determines how services are filtered when using the Service lookup in New/Manage Appointment modals. It restricts the options shown based on funding, ensuring only relevant Appointment Services appear according to the selected Service Agreement.

Show Accommodation

When managing Locations for an Appointment, this setting determines if any related Accomodation records are shown for selection. This is usually applicable to residential care scenarios.

Show Summary on Quick Complete

When quick-completing an Appointment or Shift, Maica can optionally show a summary screen which allows to the user to correct any delivery durations or quantities. This setting determines if this summary screen is shown when quick-completing.

Participants Rollup Flow

Maica offers a Salesforce Flow that enumerates all Participants on an Appointment which can then be included into the cell description. This setting specifies this Flow which can be changed or amdended as needed.

Resources Rollup Flow

Maica offers a Salesforce Flow that enumerates all Resources on an Appointment or Shift which can then be included into the cell description. This setting specifies this Flow which can be changed or amdended as needed.

Check-Out Behaviour

When checking out of an Appointment or a Shift, all delivered Appointment/Shift Services can either be marked as Completed or Not Completed by default. If marked as Not Completed, the user is required to manually set each Appointment/Shift Service to Completed during the checkout process. This setting determines which status all delivered Appointment/Shift Services will have when checking out.

Enable Appointment Tolerance Violation Policy

Maica has the ability to validate if Appointments or Shifts are delivered as they are meant to. This means the care worker checks in on time, runs the Appointment/Shift to the required duration and checks out at the right time. This setting determines if Maica validates Appointments or Shifts using this logic.

Duration Tolerance (Minutes)

This determines how many minutes the Appointment or Shift can be varied by before it is considered violated, for example: if set to 30 then any Appointment or Shift that has a duration of more than 30 minutes over the scheduled duration will be considered violated and placed Under Review.

Scheduled vs Actual Tolerance (Minutes)

This determines how many minutes the Appointment or Shift can be varied during either check-in or check-out by before it is considered violated, for example: if set to 30 then any Appointment or Shift that has is checked into or checked out of more than 30 minutes over the scheduled time will be considered violated and placed Under Review.

Flow Label

Maica - NDIS Bulk Payment Request Results File

API Name

maica__Maica_NDIS_Bulk_Payment_Request_Results_File

Type

Autolaunched Flow

Flow Label

Maica - Remittance Advice Import

API Name

maica__Maica_Remittance_Advice_Import

Type

Autolaunched Flow

Data Import Utility
here
NDISHandleRemittanceAdviceInvocable

Schedule Start

The date on which the recurring schedule starts. This is a mandatory value.

Date

Schedule End

The date on which the recurring schedule ends. This is optional and, if left blank, the schedule does not end.

Date (greater than Schedule Start)

Number of

Sets a specific number of either Appointments, Shifts, or Unavailabilities to be recurring.

Number

Frequency

Sets the frequency at which the recurring schedule is executed.

Daily Weekly Monthly Quarterly Annually

Repeat Every

Sets the repetition of days at which the recurring schedule is executed.

Number of Days

Exclude Public Holidays

If selected, Maica excludes any days marked as a public holiday(s) in Salesforce.

Yes/No

maica__Schedule_Start_Date__c - Schedule Horizon (weeks)
Schedule Evaluation Date = Schedule Start Date - Schedule Horizon (weeks)
AND(
    maica__Schedule_Evaluation_Date__c <= TODAY(),
    TODAY() <= maica__End_Date__c,
    ISPICKVAL(maica__Status__c, "Approved")
)
here
Recurring Schedule Configuration available for Appointments, Shifts, and Unavailabilities.
Location Schema
Delivery Activity Schema

Rule Name

VAL_RESOURCE_0001

Error Message

VAL_0001: The End Date cannot be before the Start Date.

Error Location

Top of Page

Error Condition Formula
AND(
    NOT(ISBLANK(maica_cc__Start_Date__c)),
    NOT(ISBLANK(maica_cc__End_Date__c)),
    maica_cc__Start_Date__c > maica_cc__End_Date__c
)

Rule Name

VAL_RESOURCE_0002

Error Message

VAL_0002: When the Resource Type is Resource, the following fields are required: Employment Type, Weekly Hours Limit, Daily Hours Limit, Weekly Hours Minimum.

Error Location

Top of Page

Error Condition Formula
AND(
ISPICKVAL(maica_cc__Resource_Type__c, "Resource"),
OR(
ISPICKVAL(maica_cc__Employment_Type__c, ""),
ISBLANK(maica_cc__Weekly_Hours_Limit__c),
ISBLANK(maica_cc__Weekly_Hours_Minimum__c),
ISBLANK(maica_cc__Daily_Hours_Limit__c)
)
)

Rule Name

VAL_RESOURCE_0003

Error Message

VAL_0003: Weekly Hours Minimum must be less than Weekly Hours Limit.

Error Location

Weekly Hours Minimum

Error Condition Formula
AND(
    NOT(ISNULL(maica_cc__Weekly_Hours_Minimum__c)),
    NOT(ISNULL(maica_cc__Weekly_Hours_Limit__c)),
    maica_cc__Weekly_Hours_Minimum__c >= maica_cc__Weekly_Hours_Limit__c
)

Rule Name

VAL_RESOURCE_0004

Error Message

VAL_0004: A related User is required when Resource Type = Resource.

Error Location

User

Error Condition Formula
AND(
    ISPICKVAL(maica_cc__Resource_Type__c, "Resource"),
    ISBLANK(maica_cc__User__c)
)

Flow Label

Maica - Resource Geocoding

API Name

maica__Maica_Resource_Geocoding

Type

Autolaunched Flow

Load Order

1

Label

ResourceDeactivation_MDTM

Load Order

2

Label

ResourceGeocode_MDTM

here
Logo

Data Import Flows

Learn about the Automation involved when Importing Data into Maica

What are the Data Import Flows?

As part of the Data Import Utility, Automation is involved to ensure it's successful completion.

When using the tool, you are prompted to select a Flow Setting that essentially tells Maica which type of Data you are wanting to Import and allows the Automation to read the files correctly. It is important to understand the logic within the Automation and the altercations to the Data that will be involved when doing so. This article explains the logic behind each Flow Setting in more detail.

Maica - NDIS Import Support Items Catalogue

This flow is designed to automate the import of NDIS support items and their associated prices based on various state-specific rates and conditions.

Flow Detail

Flow Label

Maica - NDIS Import Support Items Catalogue

API Name

maica__Maica_NDIS_Import_Support_Item_Prices

Type

Autolaunched Flow

Flow Summary

This flow imports NDIS support items and their associated prices based on state-specific rates and conditions.

  • Starts automatically and checks if the Support Item Number is present.

  • Calls the import support item Apex action if the item number is valid.

  • Passes variables like allowed states, claim types, prices for different regions, and item details.

  • Handles errors by assigning appropriate fault messages when required.

Flow Description
  1. Start (Auto-Launched Flow):

    • The flow is auto-launched and starts by verifying whether the Support Item Number is present.

    • It checks if the Support Item Number is not null or empty.

  2. Decision (Support Item Number Is Not Null):

    • Outcome: Null: If the Support Item Number is empty or null, the flow proceeds to the Handle Support Item Number Null step, which sets an error message.

    • Outcome: Not Null: If the Support Item Number is present, the flow proceeds to the Call Import Support Item step.

  3. Call Import Support Item (Apex Action):

    • The flow uses the NDISImportSupportItemsPricesInvocable Apex class to import the support item and its associated prices.

    • The following input parameters are passed to the Apex class:

      • allowedStates: The states where this item is applicable.

      • claimTypesFormula: The applicable claim types, built from multiple variables like CANC, IRSS, etc.

      • priceACT, priceNSW, priceNT, priceQLD, priceRemote, priceSA, priceTAS, priceVeryRemote, priceVIC, priceWA: The price of the support item for each state or region.

      • priceBookDescription: Describes how the item appears in the price book.

      • isQuoteRequired: A Boolean indicating if a quote is required, calculated using the quoteFormula.

      • registrationGroupCode, supportCategoryName, supportCategoryNumber, itemName, itemNumber, supportItemType, unit: Key details such as the support item's name, number, type, and unit.

  4. Handle Error (Assignment):

    • If an error occurs during any stage of the flow, the FlowFaultMessage variable is assigned the error message for tracking and troubleshooting purposes.

  5. Handle Support Item Number Null (Assignment):

    • If the Support Item Number is not provided, the flow assigns the error message: "Support Item Number is required for import."

Maica - NDIS Support Catalogue Import Configuration

This flow is designed to facilitate the configuration and import process for the NDIS Support Catalogue. It allows users to select specific areas (states) and provides the option to include additional descriptions for the generated Price Books.

Flow Detail

Flow Label

Maica - NDIS Support Catalogue Import Configuration

API Name

maica__Maica_NDIS_Support_Catalogue_Import_Configuration

Type

Screen Flow

Flow Summary

This flow streamlines the process of importing NDIS support catalogue data into Maica by allowing users to configure Price Book creation for specific states.

  • Users select states for which Price Books will be generated.

  • A description can be added for each Price Book.

  • The created Price Book records are used to organise NDIS support items based on regions.

Flow Description
  1. Start (Screen Element):

    • The flow begins with a screen to configure the NDIS Support Catalogue import.

    • It contains two key options:

      • Selection of areas (states) for which Price Books will be created.

      • An optional description field to save relevant notes on the new Price Book(s).

  2. Dynamic Choice Set (StateOptions):

    • Retrieves available states from the Pricebook2 object.

    • This dynamic choice set is used in the screen for state selection.

  3. Assignment (Assignment):

    • The selected areas (states) and the description for the Price Books are stored in the respective variables.

    • The allowedStates and priceBookDescription variables are updated based on user inputs.

Maica - Client Care Reference Data Import Handler

This flow is designed to handle the import of CSV data into the Maica system, populating various reference data objects such as Appointment Service, Availability, Checklist, Client Goal, and others. The flow allows for creating and updating records for these objects based on imported data, and provides error handling mechanisms for any issues during the import process.

Flow Detail

Flow Label

Maica - Client Care Reference Data Import Handler

API Name

maica__Maica_Client_Care_Reference_Data_Import_Handler

Type

Autolaunched Flow

Flow Summary

This flow processes CSV imports and creates or updates reference data records for the Maica system, handling various objects related to client care.

  • Determines the object type from Object_API_Name and processes it accordingly.

  • Creates or updates records for objects such as Appointment_Service, Availability, Checklist, Client_Goal, Resource, and more.

  • Provides error handling mechanisms to capture and log faults during the import process.

Flow Description
  1. Start (Auto-launched Flow):

    • The flow starts by evaluating the Object_API_Name to determine which type of record to process.

  2. Decision (DECISION_Object_API_Name):

    • Determines the object type based on Object_API_Name and routes the flow accordingly to handle specific objects like Resource, Availability, Unavailability, etc.

    • If an unknown object type is encountered, it triggers the fault message.

  3. Assignment (ASSIGN_Appointment_Service_Values):

    • Assigns values to various fields in the Appointment_Service object, such as Available_Sections__c, Claim_Types__c, Client_Note_Template__c, End_Date__c, and others.

  4. Assignment (ASSIGN_Availability_Values):

    • Assigns values to the Availability object, including fields like Active__c, Effective_From__c, Effective_To__c, Location__c, and others.

  5. Assignment (ASSIGN_Checklist_Values):

    • Assigns values to the Checklist object, such as Create_During_Quick_Complete__c, Default_Checklist_Item_Status__c, End_Date__c, and others.

  6. Record Lookup (GET_Resource):

    • Retrieves a Resource record based on the provided Resource_Name.

    • If the record is found, the flow assigns the Resource_Id and proceeds to update the relevant object.

  7. Record Create (CREATE_Appointment_Service):

    • Creates a new Appointment_Service record using the assigned values.

    • If an error occurs, the flow assigns a fault message to handle the error.

  8. Record Create (CREATE_Availability):

    • Creates a new Availability record with the provided values.

  9. Record Create (CREATE_Client_Goal):

    • Creates a Client_Goal record by assigning values like Contact__c, Goal__c, Description__c, Stage__c, and others.

Maica - Client Management Reference Data Import Handler

This flow is designed to handle the import of reference data objects for Maica Client Management via a CSV. It looks up and creates records for several Salesforce objects such as Product2, Pricebook2, Connection__c, Support_Category__c, and PricebookEntry.

Flow Detail

Flow Label

Maica - Client Management Reference Data Import Handler

API Name

maica__Maica_Client_Management_Reference_Data_Import_Handler

Type

Autolaunched Flow

Flow Summary

  • This flow imports client management reference data from CSV into Maica.

  • It handles objects such as Product2, Pricebook2, Connection__c, Support_Category__c, and PricebookEntry.

  • The flow performs the following actions:

    • Looks up existing records (e.g., Contact, Product, Support_Category).

    • Assigns values to variables (e.g., Connection__c, Product2, Support_Category__c).

    • Creates new records (e.g., Connection__c, Product2, Support_Category__c, PricebookEntry).

    • Includes decision logic to route based on the object’s API name (e.g., Product2, Pricebook2, maica__Support_Category__c).

    • Handles error conditions with fault messages (e.g., missing Standard Price Book).

Flow Description
  1. Start (Triggered by CSV):

    • The flow starts when CSV records are imported.

  2. DECISION_Object_API_Name (Decision):

    • Determines the object to process based on the Object_API_Name passed to the flow.

    • Routes the flow to handle various object types, such as Product2, Pricebook2, or maica__Support_Category__c.

  3. GET_Contact (Record Lookup):

    • Looks up the Contact object using the Contact_Name.

    • Assigns the Id of the retrieved contact to Contact_Id.

  4. ASSIGN_Connection_Values (Assignment):

    • Assigns values to a new Connection__c record (such as Contact__c, Invoice_Recipient__c, and Primary_Contact__c).

    • The assigned values are later used in the CREATE_Connection.

  5. CREATE_Connection (Record Create):

    • Creates a new Connection__c record using the values assigned from the ASSIGN_Connection_Values.

  6. GET_Product (Record Lookup):

    • Looks up a product (Product2) based on Product_Name.

    • The found product's Id is stored in Product_Id.

  7. ASSIGN_Product_Values (Assignment):

    • Assigns values to the Product2 record, including fields such as Support_Item_Type__c, GST_Code__c, and Funding_Level__c.

  8. CREATE_Product (Record Create):

    • Creates a new Product2 record based on the assigned values.

  9. GET_Standard_Price_Book (Record Lookup):

    • Fetches the standard price book if it exists and is active, storing the Id.

  10. DECISION_Standard_Price_Book_Entry (Decision):

    • Checks whether a price book entry exists for the product in the standard price book.

    • If not, routes to create the PricebookEntry.

  11. CREATE_Standard_Price_Book_Entry (Record Create):

    • Creates a new standard price book entry for the product if it does not already exist.

  12. GET_Support_Category (Record Lookup):

    • Looks up a Support_Category__c record using the Support_Category_Name.

    • Stores the category Id for further processing.

  13. ASSIGN_Support_Category_Values (Assignment):

    • Assigns values to the Support_Category__c record, such as Budget_Type__c, Category_Number__c, and Support_Purpose__c.

  14. CREATE_Support_Category (Record Create):

    • Creates a new Support_Category__c record using the assigned values.

Flows related to the BPR Remittance File Import & NDIS BPR Results File are located on the BPR File Import Flows page.

Support Item Schema
Funding Schema
How to check your Salesforce hosting location.
Booking Item Schema
Service Agreement Leave Schema
Connection Schema
Contact Schema
Resource Schema

Appointment

The Appointment object in Maica is used to manage the details of Appointment records in Maica Client Care, such as Start Date/End Date/Resource(s) etc

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Appointment object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Appointment Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Appointment Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

End Time Cannot Be Before Start Time

Ensures that the End Time cannot be set prior to the Start Time.

Validation Rule Detail

Rule Name

VAL_APPOINTMENT_0001

Error Message

VAL_0001: The End Time cannot be prior to the Start Time.

Error Location

Top of Page

Error Condition Formula
maica_cc__Scheduled_Start__c  >  maica_cc__Scheduled_End__c

Check out Date/Time Must Be After Check in Date/Time

The checkout date/time must be greater than the checkin date/time.

Validation Rule Detail

Rule Name

VAL_APPOINTMENT_0002

Error Message

VAL_0002: The checkout date/time must be greater than the checkin date/time.

Error Location

Top of Page

Error Condition Formula
maica_cc__Check_out__c <  maica_cc__Check_in__c

Cancellation Date Required When Cancellation Reason is Set

If the cancellation reason is set, then a cancellation date must be supplied.

Validation Rule Detail

Rule Name

VAL_APPOINTMENT_0003

Error Message

VAL_0003: A Cancellation Date must be entered if a Cancellation Reason is selected.

Error Location

Top of Page

Error Condition Formula
AND(
    ISBLANK(TEXT(maica_cc__Cancellation_Date__c)),
    NOT(ISBLANK(TEXT(maica_cc__Cancellation_Reason__c)))
)

Automation

Flows

The list below outlines the Flows applied to the Appointment Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Appointment Geocoding

This flow is designed to geocode the address of an appointment upon creation or update of the appointment record.

Flow Detail

Flow Label

Maica - Appointment Geocoding

API Name

maica__Maica_Appointment_Geocoding

Type

Autolaunched Flow

Flow Summary

This flow geocodes the address of an appointment and updates the appointment record with the latitude and longitude by:

  • Triggering on the creation or update of an appointment record.

  • Geocoding the address fields using an Apex action.

  • Checking for errors in the geocoding process.

  • Updating the appointment record with the geocoded latitude and longitude if no errors occur.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow is triggered upon the creation or update of an appointment record.

    • The flow runs asynchronously after the record is saved.

    • Proceeds to geocode the address.

  2. Geocode the Address (Apex Action):

    • Calls the GeocodeAddressInvocableProc Apex action to geocode the address fields.

    • Passes the address fields and the record ID as input parameters.

    • Proceeds to the decision step to check for errors.

  3. Error? (Decision):

    • Checks if there was an error during the geocoding process by evaluating the errorMessage from the Geocode_the_Address action.

    • No: If no error, proceeds to update the appointment.

    • Yes: If an error occurred, the flow ends without updating the appointment.

  4. Update Appointment (Record Update):

    • Updates the appointment record with the latitude and longitude values obtained from the geocoding process.

    • Ends the flow.

Trigger Handlers

The table below outlines the Trigger Handlers applied to the Appointment Object in Maica and their Load Order.

Trigger Handler
Load Order

1

1

2

4

5

Please refer to the list below for more detailed information on each Trigger Handler.

Appointment Time Sheet

This trigger is designed to manage the timesheets for appointments in Maica. The outcome is accurate and reliable timesheet data for all appointments, ensuring proper time management and reporting.

Detail

Load Order

1

Label

AppointmentTimeSheet_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the AppointmentTimeSheet_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the timesheet process for appointments.

  • Trigger Conditions:

    • When a new appointment (maica__Appointment__c) is created.

    • When an existing appointment is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an appointment record is created or updated, the trigger is initialised. The AppointmentTimeSheet_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the AppointmentTimeSheet_MDTM class.

    • The class methods perform the following steps:

      • Validation: The appointment data is validated to ensure it is complete and accurate.

      • Timesheet Creation/Update: Based on the appointment details, timesheet entries are created or updated to reflect the time spent on the appointment.

      • Update: The appointment record is updated with the newly created or updated timesheet data.

Trigger Outcome:

Once executed, the trigger ensures that each appointment has its timesheet entries created or updated correctly, based on the logic defined in the handler class. This helps maintain accurate timesheet data for appointments.

Appointment Status

This trigger is designed to manage the status updates for appointments in Maica. The outcome is accurate and reliable status tracking for all appointments, ensuring proper management and communication.

Detail

Load Order

1

Label

AppointmentStatus_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the AppointmentStatus_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the status updates for appointments.

  • Trigger Conditions:

    • When a new appointment (maica__Appointment__c) is created.

    • When an existing appointment is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an appointment record is created or updated, the trigger is initialised. The AppointmentStatus_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the AppointmentStatus_MDTM class.

    • The class methods perform the following steps:

      • Validation: The appointment data is validated to ensure it is complete and accurate.

      • Status Update: The appointment status is updated based on predefined criteria such as appointment type, time, and other relevant factors.

      • Notification: Relevant stakeholders are notified if necessary, ensuring that all parties are aware of the status changes.

Trigger Outcome:

Once executed, the trigger ensures that each appointment has its status updated correctly, based on the logic defined in the handler class. This helps maintain accurate status tracking for appointments.

Appointment Rollup Participants

This trigger is designed to manage the rollup of participants for appointments in Maica.

Detail

Load Order

2

Label

AppointmentRollupParticipants_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the AppointmentRollupParticipants_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the rollup of participants for appointments.

  • Trigger Conditions:

    • When a new appointment (maica__Appointment__c) is created.

    • When an existing appointment is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an appointment record is created or updated, the trigger is initialised. The AppointmentRollupParticipants_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 3.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the AppointmentRollupParticipants_MDTM class.

    • The class methods perform the following steps:

      • Validation: The participant data is validated to ensure it is complete and accurate.

      • Calculation: The total number of participants is calculated based on predefined criteria such as appointment type and participant status.

      • Update: The appointment record is updated with the newly calculated rolled-up participant data.

Trigger Outcome:

Once executed, the trigger ensures that each appointment has its participants rolled up correctly, according to the logic specified in the handler class. This helps maintain accurate participant data for appointments.

Appointment Geocoding

This trigger is designed to manage the geocoding of appointments in Maica, maintaining accurate geographical data.

Detail

Load Order

4

Label

AppointmentGeocode_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the AppointmentGeocode_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the geocoding process for appointments.

  • Trigger Conditions:

    • When a new appointment (maica__Appointment__c) is created.

    • When an existing appointment is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an appointment record is created or updated, the trigger is initialised. The AppointmentGeocode_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 4.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the AppointmentGeocode_MDTM class.

    • The class methods perform the following steps:

      • Validation: The appointment address data is validated to ensure it is complete and accurate.

      • Geocoding: The validated address data is converted into geographical coordinates using geocoding services.

      • Update: The appointment record is updated with the newly obtained geographical coordinates.

Trigger Outcome:

Once executed, the trigger ensures that each appointment is geocoded correctly, according to the logic specified in the handler class. This helps maintain accurate geographical data for appointments.

Appointment Delivery Activities

This trigger is designed to manage the delivery activities for appointments in Maica.

Detail

Load Order

5

Label

AppointmentDeliveryActivities_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the AppointmentDeliveryActivities_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the delivery activities for appointments.

  • Trigger Conditions:

    • When a new appointment (maica__Appointment__c) is created.

    • When an existing appointment is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an appointment record is created or updated, the trigger is initialised. The AppointmentDeliveryActivities_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 6.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the AppointmentDeliveryActivities_MDTM class.

    • The class methods perform the following steps:

      • Validation: The appointment data is validated to ensure it is complete and accurate.

      • Activity Creation/Update: Based on the appointment details, delivery activities are created or updated to reflect the services or tasks associated with the appointment.

      • Update: The appointment record is updated with the newly created or updated delivery activity data.

Trigger Outcome:

Once executed, the trigger ensures that each appointment has its delivery activities created or updated correctly, according to the logic specified in the handler class. This helps maintain accurate delivery activity data for appointments.

Reference Data Template

Learn about the Reference Data Template required to Import your Data into Maica

What is a Reference Data Template?

Maica provides you with a spreadsheet template in which you may enter your data. This template is called the Maica Reference Data - Import Templates and it contains a number of tabs for typical Data Objects in Maica that Reference Data may be beneficial for.

Each Data Object has a unique set of fields that need to be populated, hence the corresponding tab is specific to any particular Object. Within each tab, each row in the spreadsheet corresponds to a Salesforce record, while the columns correlate directly to Salesforce attributes.

It is crucial that the first row within each tab is not modified. Modifying or adding columns in the first row will result in errors when attempting to import your data into Maica.

The template's objective is to allow you to bulk load the necessary reference data for Maica to get you up and running.

You can download two versions of the template below:

Template Type
Description

To download a Template, click on the Template Name in the table above. Once you have opened it, simply create your own copy and start populating it.

How do I populate my template?

As mentioned above, Maica objects contain attributes of varying Data Types. So, to begin populating a Reference Data Template, lets use an example object: Appointment Services.

When preparing your reference data for loading, there are several formatting requirements that you must follow to guarantee that your data is loaded successfully.

In the downloadable template above, each column will come pre-populated with a value for each column letting you know what Data Type is expected. Remember, each column represents an attribute of the specific object. Below shows the pre-populated columns and rows for the Appointment Services object:

Here we can see Line 1 contains the attributes of the Appointment Services object, and Line 2 contains the required Data Type to input in order to populate that attribute.

So, in order to populate the attributes, we first must understand the Data Types. The table below explains each Data Type in more detail:

Data Type
Description

Now, these Data Types must be practically applied to the attributes shown in Line 1. In order to understand the formatting or values of any field, you can follow the below steps:

1. Head to the Setup

For our example we are using the Appointment Service Object. First, you must go to the Setup by clicking the Cog (as shown below) followed by clicking Setup.

2. Find the Object in the Object Manager

Once in the Setup, head to the Object Manager by clicking the following.

Then, use the Quick Find to search for the required Data Object. In this case: Appointment Service.

3. Find Attribute in Fields & Relationships

After you have selected the required object, click the Fields & Relationships tab and find the attribute you are wanting to understand the formatting or values for. For example, let's say within Appointment Services tab of our template you want to populate the Available Sections column. You can see from the template that the Data Type for this column is Multi-Select Picklist Values, but you may be wondering what these values are. So, in the Fields & Relationships of Appointment Services, find Available Sections and select it, as shown below.

Within Maica you can also find or confirm the Data Type for any Field, as shown above.

4. Find associated Values to populate your Template

After you have found the required Field, in this case Available Sections, scroll down to see the Values and their associated API Name, as shown below.

Now, you can see the required information to populate your column within the Template.

For any Picklist, always use the Values API Namewhen populating your template.

Ensure you always refer back to the required formatting of the Data Type when populating the template, as shown .

Please see below for an exmaple of how this column would be populated within the Template with the correct values and formatting.

If you require custom Picklist values, you can add them in the Values section of the Data Object by simply clicking New.

Blank Template

This is a blank template ready to be populated with your data.

Populated Template

This a template with pre-populated data that you can refer to when populating your own template.

Object API Name

This column represents the Data Object you are loading for and must be populated with a valid API name of a Maica Object. It’s required on every row to tell the import flow which object to retrieve and write the values to.

Related Record Name

Any column that references the Name value of a related Object represents a lookup field linking the record to another related record. In the Reference Data loading process we use the Name value from the related object to search for, find and relate the loaded record. In the above example, this is shown in the Related Client Note Template Name. Note, this may be called Participant Note in your Maica instance. If there is more than one record with the same Name value, the import for this row will fail. (The flow can be easily extended to reference IDs of records for loading purposes if required.)

Text Value

This field accepts free text values, however it is important to check if there are any length restrictions. To do so: Go to Setup > Object Manager > {Object Name} > Fields & Relationships and look at the field you are populating. This process is further explained below.

Rich Text Value

As per the Text Value but allows loading in of HTML formatted text.

Number Value

This field accepts numbers values, however it is important to check if there are any length restrictions or if decimals are allowed. To do so: Go to Setup > Object Manager > {Object Name} > Fields & Relationships and look at the field you are populating. This process is further explained below.

Picklist Value

This field only accepts valid available and active values from the Object Picklist. check the field under Setup > Object Manager > {Object Name} > Fields & Relationships > {Field Name} to check for valid, active values. This process is further explained below.

Multi-Select Picklist Values

As above, but allows for many values to be loaded. Each value must be valid and be separated by a semicolon ;.

Date Value

This field only accepts valid Date format values. Your Salesforce Org setting will determine the acceptable default date format, but typically this will be dd/mm/yyyy or mm/dd/yyyy.

Date/Time Value

This field only accepts valid Date/Time format values. Your Salesforce Org setting will determine the acceptable default date/time format, but typically this will be dd/mm/yyyy, hh:mm:ss.

Boolean Value

Only valid TRUE values will be accepted (field is set to FALSE by default). (TRUE, true, True, 1, yes, Yes, YES).

above
AppointmentTimeSheet_MDTM
AppointmentStatus_MDTM
AppointmentRollupParticipants_MDTM
AppointmentGeocode_MDTM
AppointmentDeliveryActivities_MDTM

Public Holiday Configuration

Learn how to configure Public Holidays within Maica

How do I configure Holidays in Maica?

In order to configure Holidays within Maica, please follow the steps outlined below:

1. Head to Setup and search for Holidays

To begin creating Holiday records, head to the Salesforce Setup and search for Holidays, as shown below.

2. Create a New Holiday

Once you have opened the Holiday tab, click the New button to create a new Holiday.

Maica supports both State and National Holidays.

Please refer to the following naming conventions for both State and National Holidays:

State Based Holidays

  • In order to create a State specific Holiday, simply ensure that you include both the Short and Long State Suffix from the table below

  • For example: to create a Victorian only Holiday for the Melbourne Cup on 01/11/2022, you need to use the following Holiday Name: Melbourne Cup (VIC) (Victoria)

National Holidays

  • In order to create a National Holiday, simply ensure that you type only the Holiday Name and do not include any reference to a State Suffix from the table below

  • For example: to create a National Holiday for Christmas Day on 25/12/2022, you need to use the following Holiday Name: Christmas Day

State Name
State Name Suffix (Short)
State Name Suffix (Long)

Victoria

(VIC)

(Victoria)

New South Wales

(NSW)

(New South Wales)

Queensland

(QLD)

(Queensland)

Western Australia

(WA)

(Western Australia)

South Australia

(SA)

(South Australia)

Tasmania

(TAS)

(Tasmania)

Australian Capital Territory

(ACT)

(Australian Capital Territory)

Northern Territory

(NT)

(Northern Territory)

National

Blank

Blank

3. Link your Holiday to a Business Hour Record

Once you have created your Holiday Records, it is crucial to link them to a Business Hour Record. To do so, first select the Holiday and then click the Add/Remove button under Business Hours, as shown below.

If you have not already defined Business Hours in Maica, you must do so first. To learn more, click here.

After clicking the Add/Remove button, you will be directed to a page which allows you choose to which Business Hours the selected Holiday applies.

In order for Maica's validation to run effectively, ensure you select Maica Holidays as your Selected Business Hours, as shown below.

Action
Description

1.

Select Maica Holidays as your Business Hours record to assign to the Holiday.

2.

Hit Add to move it from Available Business Hours to Selected Business Hours.

3.

Click Save to finalise your changes.

Once done, you will see your Business Hour record has been successfully added to your Holiday, as shown below.

How do I configure Business Hours in Maica?

In order to configure Business Hours within Maica, please follow the steps outlined below:

1. Head to Setup and search for Business Hours

To begin creating Holiday records, head to the Salesforce Setup and search for Holidays, as shown below.

2. Create New Business Hours

Once you have opened the Business Hours tab, click the New Business Hours button to create a new record.

Next, follow the below outlined steps:

Step
Note
  1. Business Hours Name

When creating a Business Hours record to associate with Holidays, ensure you name it Maica Holidays.

  1. Time Zone

Select your relevant Time Zone.

  1. Business Hours

Again, when creating a Business Hours record to associate with Holidays, leave this stage at its default value. (24 hours selected for each day).

Ensure when completing Step 1, you mark your Business Hours as Active by clicking the Checkbox located below the name input.

Finally, hit Save to finalise your Record.

Service Booking

The Service Booking object in Maica represents a PRODA Service Booking (Plan) for a given Participant.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Service Booking object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Service Booking Schema.

Automation

Flows

The list below outlines the Flows applied to the Service Booking Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Booking 90 Days Before Expiration Notification

This flow is designed to send an email notification 90 days before the expiration of a service booking.

Flow Detail

Flow Summary

This flow sends an email notification 90 days before the expiration of a service booking by:

  • Detecting changes to service booking records and scheduling the flow to run 90 days before the end date.

  • Checking if the email template is set and if the end date is in the future.

  • Determining the email recipient based on the email setting.

  • Sending the email notification to the determined recipient.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow is initiated upon the creation or update of a service booking record.

    • Scheduled to run 90 days before the service booking's end date.

    • Proceeds to a placeholder assignment to fix packaging issues.

  2. Is Template in Email Setting Null And End Date in Future? (Decision):

    • Checks if the email template is set and if the end date of the service booking is in the future.

    • If the conditions are met, proceeds to determine the email recipient.

  3. To Whom Should This Message Be Delivered? (Decision):

    • Determines the recipient of the email based on the email setting:

      • If the recipient is the current participant owner, sets the user ID to the participant owner ID and proceeds to send the email.

      • If the recipient is a specific user and the user ID is set in the email setting, sets the user ID to the specified user ID and proceeds to send the email.

  4. Set Service Booking Participant Owner Id (Assignment):

    • Sets the user ID to send the email to the participant's owner ID.

    • Proceeds to send the email.

  5. Set User Id (Assignment):

    • Sets the user ID to send the email to the user ID specified in the email setting.

    • Proceeds to send the email.

  6. Send Email (Apex Action):

    • Calls the SendEmailInvocable Apex action to send the email.

    • Passes the email template, sender's email address, and recipient's user ID as input parameters.

    • Ends the flow.

Booking Utilisation Change Notification

This flow is designed to send an email notification when the utilisation of a service booking crosses a specified threshold.

Flow Detail

Flow Summary

This flow sends an email notification when the utilisation of a service booking crosses a specified threshold by:

  • Detecting changes to service booking records.

  • Checking if the email template is set.

  • Determining whether the email notification should be sent based on the utilisation thresholds.

  • Identifying the email recipient based on the email settings.

  • Sending the email notification to the determined recipient.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow is triggered upon the creation or update of a service booking record.

    • The flow runs asynchronously after the record is saved.

    • It proceeds to check if the email template is set.

  2. Is Template in Email Setting Null? (Decision):

    • Checks if the email template specified in the email settings is not null.

    • If the template is set, proceeds to check if the email notification should be sent.

  3. Should The Email Notification Be Sent? (Decision):

    • Determines whether the email notification should be sent based on the following conditions:

      • The current utilisation is not null.

      • The previous utilisation is not null.

      • The previous utilisation is less than the threshold specified in the email setting.

      • The current utilisation is greater than the threshold specified in the email setting.

    • If all conditions are met, proceeds to determine the email recipient.

  4. To Whom Should This Message Be Delivered? (Decision):

    • Determines the recipient of the email based on the email setting:

      • If the recipient is the current participant owner, sets the user ID to the participant owner ID.

      • If the recipient is a specific user and the user ID is set in the email setting, sets the user ID to the specified user ID.

    • Proceeds to send the email.

  5. Set Service Booking Participant Owner Id (Assignment):

    • Sets the user ID to send the email to the participant's owner ID.

    • Proceeds to send the email.

  6. Set User Id (Assignment):

    • Sets the user ID to send the email to the user ID specified in the email setting.

    • Proceeds to send the email.

  7. Send Email (Apex Action):

    • Calls the SendEmailInvocable Apex action to send the email.

    • Passes the email template, sender's email address, and recipient's user ID as input parameters.

    • Ends the flow.

  8. Handle Error (Assignment):

    • If an error occurs during the process, assigns the error message to the FlowFaultMessage variable.

Flow Label

Maica - Booking 90 Days Before Expiration Notification

API Name

maica__Booking_90_Days_Before_Expiration_Notification

Type

Autolaunched Flow

Flow Label

Maica - Booking Utilisation Change Notification

API Name

maica__Booking_Utilisation_Change_Notification

Type

Autolaunched Flow

here

Invoice

An Invoice represents the financial component following an instance of Service Delivery.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Invoice object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Invoice Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Invoice Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Funding Type Required When Invoice is Saved

This rule ensures that the Funding Type is populated when the Invoice is saved.

Validation Rule Detail

Rule Name

VAL_INVOICE_0001

Error Message

VAL_0001: Please ensure that the Funding Type is provided.

Error Location

Funding Type

Error Condition Formula
ISPICKVAL(maica_cc__Funding_Type__c, "")

Restrict Invoice Amount Change

This rule ensures that the Invoice Total Amount cannot be changed when a corresponding Stripe Invoice exists.

Validation Rule Detail

Rule Name

Restrict_Invoice_Amount_Change

Error Message

The Total Amount cannot be be updated as there is a corresponding Stripe Invoice

Error Location

Top of Page

Error Condition Formula
AND(
    NOT(ISBLANK(maica__Stripe_Invoice_ID__c)),
    ISCHANGED(maica__Total_Amount__c)
)

Automation

Flows

The list below outlines the Flows applied to the Invoice Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Cancel Invoice

This flow is designed to cancel an invoice by updating its status to "Cancelled."

Flow Detail

Flow Label

Maica - Cancel Invoice

API Name

maica__Maica_Cancel_Invoice

Type

Screen Flow

Flow Summary

This flow is designed to cancel an invoice by updating its status to "Cancelled".

  • Retrieves an invoice.

  • Checks the invoice status.

  • Allows the user to confirm cancellation.

  • Updates the invoice status to "Cancelled".

  • Notifies the user of successful cancellation.

Flow Description
  1. Start (Record-Triggered Flow):

    • Object: Invoice__c

    • Trigger: When the invoice record is updated or created.

    • Input Variable: recordId

  2. Get Invoice (Record Lookup):

    • Filters: Retrieves the invoice record where the Id matches recordId.

    • Connector: Proceeds to check the invoice status.

  3. Invoice Status (Decision):

    • Conditions: Checks if the invoice status is "Cancelled".

    • If "Cancelled": Displays the "Invoice Cancelled" screen.

    • If not "Cancelled": Proceeds to the "Cancel Invoice" screen.

  4. Cancel Invoice (Screen):

    • Displays a confirmation message asking the user to confirm the cancellation of the invoice.

    • Connector: Proceeds to set the invoice as cancelled upon confirmation.

  5. Set Invoice Cancelled (Assignment):

    • Sets the Cancelled__c field of the invoice to true.

    • Connector: Proceeds to update the invoice.

  6. Update Invoice (Record Update):

    • Updates the invoice record with the cancelled status.

    • Connector: Proceeds to display the "Invoice Cancelled" screen.

  7. Invoice Cancelled (Screen):

    • Displays a message confirming that the invoice has been cancelled.

Invoice Status Management

This flow evaluates and updates the status of an invoice based on its payment details and other related conditions.

Flow Detail

Flow Label

Maica - Invoice Status Management

API Name

maica__Invoice_Status_Management

Type

Autolaunched Flow

Flow Summary

This flow ensures that the invoice status is accurately updated based on the payment details and other conditions.

  • Starts on invoice creation or update.

  • Evaluates the status based on various conditions.

  • Assigns the appropriate status (Cancelled, Not Paid, Partially Paid, Fully Paid).

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow begins when an invoice is created or updated.

    • It is triggered before the record is saved.

  2. Status Evaluation (Decision):

    • The flow checks the status of the invoice based on various conditions:

      • If the invoice is cancelled, it proceeds to set the status to "Cancelled".

      • If all line items are not paid, it proceeds to set the status to "Not Paid".

      • If the invoice is partially paid and managed by an agency, it checks further conditions and then sets the status to "Partially Paid".

      • If the invoice is fully paid and managed by an agency, it checks further conditions and then sets the status to "Fully Paid".

      • For non-agency managed invoices, it similarly checks and sets the status to "Partially Paid" or "Fully Paid" based on payment details.

  3. Set Cancelled (Assignment):

    • Sets the invoice status to "Cancelled".

  4. Set Not Paid Status (Assignment):

    • Sets the invoice status to "Not Paid".

  5. Set Partially Paid Status (Assignment):

    • Sets the invoice status to "Partially Paid".

  6. Set Fully Paid Status (Assignment):

    • Sets the invoice status to "Fully Paid".

Trigger Handlers

The table below outlines the Trigger Handlers applied to the Invoice Object in Maica and their Load Order.

Trigger Handler
Load Order

1

1

1

2

10

Please refer to the list below for more detailed information on each Trigger Handler.

Invoice Manage Claim Schedule

This trigger is designed to manage the claim schedule for invoices in Maica.

Detail

Load Order

1

Label

InvoiceManageClaimSchedule_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the InvoiceManageClaimSchedule_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the claim schedule process for invoices.

  • Trigger Conditions:

    • When a new invoice (maica__Invoice__c) is created.

    • When an existing invoice is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an invoice record is created or updated, the trigger is initialised. The InvoiceManageClaimSchedule_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the InvoiceManageClaimSchedule_MDTM class.

    • The class methods perform the following steps:

      • Validation: The invoice data is validated to ensure it is complete and accurate.

      • Claim Scheduling: Based on the invoice details, claims are scheduled to reflect the payment plan and due dates.

      • Update: The invoice record is updated with the newly scheduled claim data.

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its claim schedule managed correctly, according to the logic specified in the handler class. This helps maintain accurate claim schedule data for invoices.

Invoice Next Schedule Date

This trigger is designed to manage the next scheduled date for invoices in Maica. This ensures correct calculation of the next scheduled date for invoices, maintaining accurate scheduling data.

Detail

Load Order

1

Label

InvoiceNextScheduledDate_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the InvoiceNextScheduledDate_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the next scheduled date process for invoices.

  • Trigger Conditions:

    • When a new invoice (maica__Invoice__c) is created.

    • When an existing invoice is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

  1. Initialisation:

    • When an invoice record is created or updated, the trigger is initialised. The InvoiceNextScheduledDate_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the InvoiceNextScheduledDate_MDTM class.

    • The class methods perform the following steps:

      • Validation: The invoice data is validated to ensure it is complete and accurate.

      • Date Calculation: Based on the invoice details, the next scheduled date is calculated to reflect the payment plan and due dates.

      • Update: The invoice record is updated with the newly calculated next scheduled date.

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its next scheduled date calculated correctly, according to the logic specified in the handler class. This helps maintain accurate scheduling data for invoices.

Invoice Defaults

This trigger is designed to manage the default values for invoices in Maica.

Detail

Load Order

1

Label

InvoiceDefaults_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the InvoiceDefaults_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the setting of default values for invoices.

  • Trigger Conditions:

    • When a new invoice (maica__Invoice__c) is created.

    • When an existing invoice is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an invoice record is created or updated, the trigger is initialised. The InvoiceDefaults_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the InvoiceDefaults_MDTM class.

    • The class methods perform the following steps:

      • Validation: The invoice data is validated to ensure it is complete and accurate.

      • Default Setting: Based on predefined criteria, default values such as payment terms, due dates, and invoice status are set.

      • Update: The invoice record is updated with the newly set default values.

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its default values set correctly, according to the logic specified in the handler class. This helps maintain accurate and consistent data for invoices.

Invoice Rollup Expenditure

This trigger is designed to manage the rollup of expenditures for invoices in Maica.

Detail

Load Order

2

Label

InvoiceRollupExpenditure_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the InvoiceRollupExpenditure_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the rollup expenditure process for invoices.

  • Trigger Conditions:

    • When a new invoice (maica__Invoice__c) is created.

    • When an existing invoice is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an invoice record is created or updated, the trigger is initialised. The InvoiceRollupExpenditure_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the InvoiceRollupExpenditure_MDTM class.

    • The class methods perform the following steps:

      • Validation: The expenditure data is validated to ensure it is complete and accurate.

      • Calculation: The total expenditure is calculated based on predefined criteria such as item type and financial rules.

      • Update: The invoice record is updated with the newly calculated rolled-up expenditure data.

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its expenditures rolled up correctly, according to the logic specified in the handler class. This helps maintain accurate financial data for invoices.

Invoice Claim

This trigger is designed to manage the claim process for invoices in Maica. This ensures correct generation of claims for invoices, maintaining accurate claim data.

Detail

Load Order

10

Label

InvoiceClaim_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the InvoiceClaim_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the claim process for invoices.

  • Trigger Conditions:

    • When a new invoice (maica__Invoice__c) is created.

    • When an existing invoice is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an invoice record is created or updated, the trigger is initialised. The InvoiceClaim_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 10.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the InvoiceClaim_MDTM class.

    • The class methods perform the following steps:

      • Validation: The invoice data is validated to ensure it is complete and accurate.

      • Claim Generation: Based on the invoice details, claims are generated to reflect the amounts and payment plans specified.

      • Update: The invoice record is updated with the newly generated claim data.

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its claims processed correctly, according to the logic specified in the handler class. This helps maintain accurate claim data for invoices.

Invoice Line Item

The Invoice Line Item object in Maica represents the specific Item level detail associated with an Invoice.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Invoice Line Item object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Invoice Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Invoice Line Item Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Support Item is Mandatory

This rule makes sure the Support Item is mandatory.

Validation Rule Detail

Rule Name

VAL_INVOICE_LINE_ITEM_0001

Error Message

VAL_0001: The Support Item is mandatory.

Error Location

Support Item

Error Condition Formula
ISBLANK(maica_cc__Support_Item__c)

Automation

Flows

The list below outlines the Flows applied to the Invoice Line Item Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Status Management

This flow evaluates and updates the status of an invoice line item.

Flow Detail

Flow Label

Maica - Invoice Line Item Status Management

API Name

maica__Invoice_Line_Item_Status_Management

Type

Autolaunched Flow

Flow Summary

This flow ensures that the invoice line item status is accurately updated based on the calculated values and specified conditions.

  • Starts on invoice line item creation or update.

  • Evaluates the status based on various conditions and calculations.

  • Assigns the appropriate status (Entered, Claimed, Fully Paid, Partially Paid, Not Paid).

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow begins when an invoice line item is created or updated.

    • It is triggered before the record is saved.

  2. Set Line Total and GST (Assignment):

    • Calculates and assigns the line total, GST amount, and amount for the invoice line item.

  3. Evaluate Status (Decision):

    • The flow checks the status of the invoice line item based on various conditions:

      • Claim Type = Home Care Package: Proceeds to evaluate further conditions.

      • Entered: If the line total is greater than 0, the claim count is 0, the claim balance equals the line total, and the paid amount is 0, it sets the status to "Entered".

      • Claimed: If the line total is greater than 0, the claim count is greater than 0, the claim balance equals the line total, and the paid amount is 0, it sets the status to "Claimed".

      • Fully Paid: If the line total is greater than 0, the claim count is greater than 0, the claim balance is less than or equal to 0, and the paid amount is greater than or equal to the line total, it sets the status to "Fully Paid".

      • Partially Paid: If the line total is greater than 0, the claim count is greater than 0, the claim balance is greater than 0 but less than the line total, and the paid amount is less than the line total, it sets the status to "Partially Paid".

      • Not Paid: If the line total is greater than 0, the claim count is greater than 0, the claim balance is greater than 0, and the paid amount is 0, it sets the status to "Not Paid".

  4. Set Entered Status (Assignment):

    • Sets the invoice line item status to "Entered".

  5. Set Claimed Status (Assignment):

    • Sets the invoice line item status to "Claimed".

  6. Set Fully Paid Status (Assignment):

    • Sets the invoice line item status to "Fully Paid".

  7. Set Partially Paid Status (Assignment):

    • Sets the invoice line item status to "Partially Paid".

  8. Set Not Paid Status (Assignment):

    • Sets the invoice line item status to "Not Paid".

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Invoice Line Item Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Invoice Line Rollup Expenditure

This trigger is designed to manage the rollup of expenditures for invoice line items in Maica.

Detail

Load Order

1

Label

InvoiceLineRollupExpenditure_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the InvoiceLineRollupExpenditure_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the rollup expenditure process for invoice line items.

  • Trigger Conditions:

    • When a new invoice line item (maica__Invoice_Line_Item__c) is created.

    • When an existing invoice line item is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an invoice line item record is created or updated, the trigger is initialised. The InvoiceLineRollupExpenditure_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the InvoiceLineRollupExpenditure_MDTM class.

    • The class methods perform the following steps:

      • Validation: The expenditure data for each line item is validated to ensure it is complete and accurate.

      • Calculation: The total expenditure is calculated based on the line items of the invoice, taking into account the item types and financial rules.

      • Update: The invoice record is updated with the newly calculated rolled-up expenditure data.

Trigger Outcome:

Once executed, the trigger ensures that each invoice line item has its expenditures rolled up correctly, according to the logic specified in the handler class. This helps maintain accurate financial data for invoices.

Invoice Line Booking Item

This trigger is designed to manage the booking items for invoice line items in Maica.

Detail

Load Order

2

Label

InvoiceLineBookingItem_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the InvoiceLineBookingItem_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the booking items process for invoice line items.

  • Trigger Conditions:

    • When a new invoice line item (maica__Invoice_Line_Item__c) is created.

    • When an existing invoice line item is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an invoice line item record is created or updated, the trigger is initialised. The InvoiceLineBookingItem_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the InvoiceLineBookingItem_MDTM class.

    • The class methods perform the following steps:

      • Validation: The booking item data for each line item is validated to ensure it is complete and accurate.

      • Linking: Booking items are linked to the corresponding invoice line items, ensuring that the relationship between booking items and invoice line items is correctly established.

      • Update: The invoice line item record is updated with the newly linked booking item data.

Trigger Outcome:

Once executed, the trigger ensures that each invoice line item has its booking items linked correctly, according to the logic specified in the handler class. This helps maintain accurate booking item data for invoice line items.

Agreement Item

The Agreement object in Maica represents the specific Products (Support Items) to be delivered as part of the Service Agreement

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Agreement Item object in Maica. Please refer to the table below for detailed information.

Click to view and download the complete Agreement Item Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Agreement Item Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Start Date Cannot Be After End Date

Ensures that the start date cannot be after the end date of any Agreement Item.

Validation Rule Detail

Automation

Trigger Handlers

The table below outlines the Trigger Handlers applied to the Agreement Item Object in Maica and their Load Order.

Trigger Handler
Load Order

Please refer to the list below for more detailed information on each Trigger Handler.

Agreement Item Support Item

This trigger is designed to manage the support items of agreement items in Maica.

Detail
Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the AgreementItemSupportItem_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the support items for agreement items.

  • Trigger Conditions:

    • When a new agreement item (maica__Agreement_Item__c) is created.

    • When an existing agreement item is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an agreement item record is created or updated, the trigger is initialised. The AgreementItemSupportItem_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the AgreementItemSupportItem_MDTM class.

    • The class methods perform the following steps:

      • Validation: The support item data is validated to ensure it is complete and accurate.

      • Association: The support items are associated with the agreement items based on predefined criteria such as item type and service requirements.

      • Update: The agreement item record is updated with the associated support item data.

Trigger Outcome:

Once executed, the trigger ensures that each agreement item has its support items associated correctly, based on the logic defined in the handler class. This helps maintain accurate and complete data for agreement items and their support items.

Agreement Item Estimated Expenditure

This trigger is designed to manage the estimated expenditure of agreement items in Maica.

Detail
Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the AgreementItemEstExpenditure_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the estimated expenditure process for agreement items.

  • Trigger Conditions:

    • When a new agreement item (maica__Agreement_Item__c) is created.

    • When an existing agreement item is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an agreement item record is created or updated, the trigger is initialised. The AgreementItemEstExpenditure_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the AgreementItemEstExpenditure_MDTM class.

    • The class methods perform the following steps:

      • Validation: The agreement item data is validated to ensure it is complete and accurate.

      • Calculation: The estimated expenditure is calculated based on predefined criteria such as item type and service duration.

      • Update: The agreement item record is updated with the newly calculated estimated expenditure data.

Trigger Outcome:

Once executed, the trigger ensures that each agreement item has its estimated expenditure calculated correctly, based on the logic defined in the handler class. This helps maintain accurate financial data for agreement items.

Agreement Item Rollup Expenditure

This trigger is designed to manage the rollup of expenditures for agreement items in Maica.

Detail
Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the AgreementItemRollupExpenditure_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the rollup expenditure process for agreement items.

  • Trigger Conditions:

    • When a new agreement item (maica__Agreement_Item__c) is created.

    • When an existing agreement item is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an agreement item record is created or updated, the trigger is initialised. The AgreementItemRollupExpenditure_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the AgreementItemRollupExpenditure_MDTM class.

    • The class methods perform the following steps:

      • Validation: The expenditure data is validated to ensure it is complete and accurate.

      • Calculation: The total expenditure is calculated based on predefined criteria such as item type and financial rules.

      • Update: The agreement item record is updated with the newly calculated rolled-up expenditure data.

Trigger Outcome:

Once executed, the trigger ensures that each agreement item has its expenditures rolled up correctly, based on the logic defined in the handler class. This helps maintain accurate financial data for agreement items.

Agreement Item Total Allocated

This trigger is designed to manage the total allocation of agreement items in Maica.

Detail
Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the AgreementItemTotalAllocated_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the total allocation process for agreement items.

  • Trigger Conditions:

    • When a new agreement item (maica__Agreement_Item__c) is created.

    • When an existing agreement item is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an agreement item record is created or updated, the trigger is initialised. The AgreementItemTotalAllocated_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 3.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the AgreementItemTotalAllocated_MDTM class.

    • The class methods perform the following steps:

      • Validation: The allocation data is validated to ensure it is complete and accurate.

      • Calculation: The total allocated amount is calculated based on predefined criteria such as item type and allocation rules.

      • Update: The agreement item record is updated with the newly calculated total allocated data.

Trigger Outcome:

Once executed, the trigger ensures that each agreement item has its total allocated amount calculated correctly, based on the logic defined in the handler class. This helps maintain accurate financial data for agreement items.

Rule Name

VAL_AGREEMENT_ITEM_0001

Error Message

VAL_0001: Start Date cannot be after End Date.

Error Location

Top of Page

Error Condition Formula
maica_cc__Start_Date__c  >  maica_cc__End_Date__c

AgreementItemSupportItem_MDTM

1

AgreementItemEstExpenditure_MDTM

2

AgreementItemRollupExpenditure_MDTM

2

AgreementItemTotalAllocated_MDTM

3

Load Order

1

Label

AgreementItemSupportItem_MDTM

Load Order

2

Label

AgreementItemEstExpenditure_MDTM

Load Order

2

Label

AgreementItemRollupExpenditure_MDTM

Load Order

3

Label

AgreementItemTotalAllocated_MDTM

here
InvoiceManageClaimSchedule_MDTM
InvoiceNextScheduledDate_MDTM
InvoiceDefaults_MDTM
InvoiceRollupExpenditure_MDTM
InvoiceClaim_MDTM

Claiming Process

Learn about Maica's Claiming Process Generation logic.

Claiming Overview

In Maica, the Support at Home Claim Submission process enables you to generate and submit claim batches to Services Australia, retrieve the status of your claims, and automatically update your invoices and budgets based on the response received.


Purpose

The Support at Home Claim Submission process is designed to:

  • Generate a claim batch for submission to Services Australia via API.

  • Use a Quick Action to check the claim status after submission.

  • Update invoice and line item records based on the claim’s final status (e.g., paid).

  • Output Payment Request records in line with responses from Services Australia.


The Process

The process is linear and consists of the following stages:

  1. Generate Claim Batch and Payment Requests

  2. Upload Invoices and Invoice Line Items to Services Australia

  3. Submit Claim Record to Services Australia

  4. Use Quick Action (QA) to retrieve Claim Status

  5. Retrieve Payment Statement and update Claim Batch

  6. Retrieve Updated Invoice Statuses

  7. Retrieve Payment Item Details for Invoice Line Items

  8. Refresh Care Recipient Budget data

Each stage of this process is covered in detail in this article.

To watch a full Video Demonstration of this process, click .


1. Generate Claim Batch and Payment Requests

Purpose

Initiate a Support at Home Claim Batch by applying filter criteria to Invoice Line Item records. Records that meet the criteria will have Payment Request records generated and linked to a new Claim Batch.


User Action

The Generate Claim Batch quick action initiates the process, launching a modal for filter input.


UI Behaviour

The modal captures:

  • Start Date / End Date: Defines the date range for eligible Invoice Line Item records.

  • Service Provider: Multi-select lookup field.

  • Funding Type: Picklist field.

The modal provides flexibility to configure submission parameters for targeted claim batch generation.


Invoice Line Item Filtering Logic

Only Invoice Line Items where the related Invoice Claim Status is set to Open will be considered for inclusion in the batch.

Modal Input
Field
Notes

Start Date & End Date

maica_cc__Service_Date__c

The service date must fall within the selected range

Service Provider

maica_cc__Invoice__r.maica_cc__Service_Provider__c

Must match the provider(s) selected in the modal

Funding Type

maica_cc__Invoice__r.maica_cc__Funding_Type__c

Must match the funding type selected in the modal


Payment Request Field Mapping

The table below shows how fields from the Invoice Line Item are mapped into the newly created Payment Request:

Invoice Line Item Field
Payment Request Field

Id

maica_cc__Invoice_Line_Item__c

maica__Amount__c

maica_cc__Claimed_Amount__c

Process Outcome

  • Invoice Line Item records that meet the provided criteria are retrieved.

  • Retrieved Invoice Line Item records have a Payment Request record generated and linked to the Claim Batch via a Claim Batch Lookup.

  • This completes the initial generation of the claim batch.

  • The Generate Claim Batch quick action can be launched again at any time prior to submission of the claim to refresh or add additional Items to the existing Claim Batch


2. Upload Invoices and Invoice Line Items to Services Australia

Purpose

Upload the generated Claim Batch Invoice and Invoice Line Item records to Services Australia for processing.


User Action

User clicks the Submit Claim button in the Quick Action

  • A confirmation message is to be displayed to the user

Once done, the modal will update and alert the user that the Claim has been submitted.


System Action

Using the Invoices API, Maica:

  • Groups Invoice Line Item records by their parent Invoice.

  • For each parent Invoice:

    • Posts a new Invoice record using the API POST method (mapping in the following Google Sheet)

    • Upon successful creation, receives a Services Australia Invoice ID.

    • Update the Invoice record in Maica with the following:

      • Services Australia Invoice ID = maica_cc__Invoice__c.maica_cc__Aged_Care_Invoice_ID__c

      • Invoice Closure Date (maica_cc__Invoice__c.maica_cc__Invoice_Closure_Date__c) = YESTERDAY

      • Invoice Claim Status (maica_cc__Invoice__c.maica_cc__Claim_Status__c) = SUBMITTED

    • Posts all related Invoice Line Items (child records) using the retrieved Services Australia Invoice ID as the parent reference.

    • Upon successful creation, receives a Services Australia Invoice Item ID.

      • Services Australia Invoice Item ID =maica_cc__Invoice_Line_Item__c.maica_cc__Aged_Care_Invoice_Item_ID__c


Record Updates in Maica

Invoice Object

Field
Update
Mapping

Aged Care Invoice ID

Set to Services Australia Invoice ID

maica_cc__Aged_Care_Invoice_ID__c

Invoice Closure Date

Set to YESTERDAY

maica_cc__Invoice_Closure_Date__c

Invoice Claim Status

Set to SUBMITTED

maica_cc__Claim_Status__c

Invoice Line Item Object

Field
Update
Mapping

Aged Care Invoice Item ID

Set to Services Australia Invoice Item ID

maica_cc__Aged_Care_Invoice_Item_ID__c


Data Model Alignment

The data model in Services Australia mirrors our own:

  • Invoice (parent record) directly maps to the local Invoice object.

  • Invoice Item (child record) directly maps to the local Invoice Line Item object.


Process Outcome

  • Invoice records are successfully submitted to Services Australia and marked as submitted in Maica.

  • Related Invoice Line Items are also posted and linked to their parent Invoices using the returned IDs.


3. Submit Claim Record to Services Australia

Purpose

Initiate the submission of the Claim Record associated with the batch to Services Australia.

User Action

No direct user interaction. This step is automatically initiated as part of the Submit Claim quick action previously selected.

System Action

Using the Claim API, the system:

  • Posts a Claim record populated with mapped values from the Claim Batch record / Maica Settings

  • Upon successful creation, receives a Services Australia Claim ID.

  • Uploads an array of associated Invoice IDs linked to the Claim, matching them to the submitted Invoices in Services Australia's system (mapping below)


Claim API Mapping – POST

Payload Field
Mapping

serviceProviderId

Taken from Maica Settings

invoices[].invoiceId

maica_cc__Invoice__c.maica_cc__Aged_Care_Invoice_ID__c


Claim API Mapping – RESPONSE

Payload Field
Mapping

claimId

maica_cc__Claim_Batch__c.maica_cc__Aged_Care_Claim_ID__c

status

maica_cc__Claim_Batch__c.maica_cc__Claim_Status__c

"CLAIMED"

Updates all associated Invoices' maica_cc__Claim_Status__c


Process Outcome

  • A Claim Record is created and linked to the Invoices in Services Australia.

  • The returned Claim ID is stored for visibility and future updates.


Next Step

Once the Claim is successfully submitted and its status is returned as Claimed, a new quick action called Check Claim Status becomes available on the Claim Batch record.


4. Check Claim Status

Purpose

Check the latest status of the submitted claim in Services Australia to determine if it has progressed to a final outcome such as ‘Paid’.

User Action

User selects the Check Claim Status quick action available on the Claim Batch record.

System Action

Using the Claim API, the system:

  • Retrieves the current status of the submitted Claim from Services Australia.

  • If the claim status has changed, updates the local Claim Batch and related records accordingly.

  • Returns additional attributes where applicable, such as:

    • Updated Claim Status (e.g., BeingCalculated, PendingApproval, Approved)

    • Claim Paid Date


Claim API → Claim Response – Field Mapping

Payload Field
Mapping
Notes

status

maica_cc__Claim_Status__c

- BeingCalculated = The claim is being calculated - PendingApproval = The claim is pending approval - Cancelled = The claim has been cancelled/rejected - Approved = The claim has been approved for payment - Paid = The claim is paid

paymentDate

maica_cc__Claim_Paid_Date__c

Only populated when maica_cc__Claim_Status__c = Approved


Process Outcome

  • The latest Claim Status and Claim Paid Date are updated on the Claim Batch record.

  • Triggers follow-up steps based on the claim’s updated status.


5. Retrieve Payment Statement and Update Claim Batch

Purpose

Capture final payment information from Services Australia after a claim has been marked as either Paid or Successful.

System Action

Once the Claim Batch status is updated to Paid, Maica automatically performs the following actions:

  • Initiates a callout to the Payment Statement API.

  • Retrieves relevant financial data from Services Australia, including:

    • Payment Amount Summaries

    • Claim Summaries

  • Maps and updates the retrieved values to the appropriate fields on the Claim Batch record.

Field Mapping

Payment Statement API → Claim Batch Mapping

Payload Field
Mapping

claimTotal

maica_cc__Claim_Total__c

totalPaid

maica_cc__Paid_Total__c

compensationReduction

maica_cc__Care_Recipient_Contribution_Amount__c

careRecipientIndividualContribution

maica_cc__Compensation_Reduction_Amount__c

heldoverPreviousPeriod

maica_cc__Previous_Held_Over_Payment_Amount__c

outstandingHeldover

maica_cc__Current_Held_Over_Payment_Amount__c

Process Outcome

  • The Claim Batch record is enriched with final payment figures.

  • Ensures all claim metrics and financial data are accurately captured and recorded.


6. Retrieve Updated Invoice Statuses

Purpose

Update the status of individual Invoice records associated with the Claim Batch.

System Action

  • Using the Invoices API, the system:

    • Performs a callout using the Claim ID as the key to query all related Invoice records.

    • Retrieves the latest status information for each Invoice:

      • Based on a match of maica_cc__Invoice__c.maica_cc__Aged_Care_Invoice_ID__c

    • Updates the local Invoice records accordingly with any claim status changes returned.

Invoice API → Invoice Mapping

Payload Field
Mapping

status

maica_cc__Claim_Status__c

Process Outcome

  • Invoice records associated with the Claim Batch reflect their final processed status from Services Australia.


7. Retrieve Payment Item Details for Invoice Line Items

Purpose

Retrieve detailed payment information for each Invoice Line Item linked to the Claim Batch (via Payment Request records).

System Action

  • For each Invoice Line Item associated with the Claim Batch, the system performs a callout to the Payment Item Reporting API.

  • It retrieves specific payment data for the corresponding Payment Item in Services Australia’s system.

    • This is done via the Invoice → Invoice Line Item relationship using the field maica_cc__Invoice_Line_Item__c.maica_cc__Aged_Care_Invoice_Item_ID__c.

    • All Invoice records related to the Claim Batch are retrieved.

    • The system then iterates through each related Invoice Line Item and matches on ItemId = maica_cc__Invoice_Line_Item__c.maica_cc__Aged_Care_Invoice_Item_ID__c.

  • Retrieved data is used to update Payment Request records in Maica.

  • Relevant claim and contribution fields are mapped and stored as shown below.

Payment Item Reporting API → Payment Request Mapping

Payload Field
Mapping
Notes

itemId

maica_cc__Invoice_Line_Item__r.maica_cc__Aged_Care_Invoice_Item_ID__c

claimSubmissionDate

maica_cc__Claim_Date__c

claimApprovedDate

N/A

paymentDate

maica_cc__Paid_Date__c

compensationReduction

maica_cc__Compensation_Reduction_Amount__c

individualContributionAmount

maica_cc__Care_Recipient_Contribution_Amount__c

paymentDetermination

maica_cc__Paid_Amount__c

(status)

maica_cc__Status__c

Set to PAID

Process Outcome

  • Each Invoice Line Item is updated with precise payment data reflecting actual amounts paid.

  • Enables granular financial tracking at the individual service delivery level.


8. Refresh Care Recipient Budgets

Purpose

As part of the finalisation of the claims process, this step ensures your care recipients’ budget data is refreshed and aligned with the completed and paid claim.

System Action

  • Triggered automatically once Step 7 completes successfully.

  • The system:

    • Identifies all unique care recipient IDs from the claim items in the batch.

    • For each unique care recipient ID:

      • Executes a call to the Budgets API endpoint.

      • Retrieves current budgets and creates or updates related Plan Budget and Entitlement records.

      • Only budgets where the End Date is within 60 days of today are included.

Outcome

You can now dispatch invoices for any remaining client contribution amounts that were not covered in the submitted claim.

Appointment Schema
Service Booking Schema
Agreement Item Schema

Unavailability

This object in Maica is used to define specific dates or periods where the Resource is unavailable, i.e. when they are not able to work.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Unavailability object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Support Category Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Unavailability Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Unavailable To Date Cannot Be Before Unavailable From Date

Ensures that the Unavailable To date cannot be before the Unavailable From date.

Validation Rule Detail

Rule Name

VAL_UNAVAILABILITY_0001

Error Message

VAL_0001: The Unavailable To date cannot be before the Unavailable From date

Error Location

Unavailable To

Error Condition Formula
AND(
NOT(ISBLANK(maica_cc__Unavailable_From__c)),
NOT(ISBLANK(maica_cc__Unavailable_To__c)),
maica_cc__Unavailable_From__c > maica_cc__Unavailable_To__c
)

Unavailable To / Unavailable From Cannot Be Changed if Status is Approved

Prevents editing the date fields once the Unavailability record has been marked as Approved.

Validation Rule Detail

Rule Name

VAL_UNAVAILABILITY_0003

Error Message

VAL_0003: Unavailable From and Unavailable To cannot be changed when the Status is Approved.

Error Condition Formula
AND(
  ISPICKVAL(maica_cc__Status__c, 'Approved'),
  OR(
    ISCHANGED(maica_cc__Unavailable_From__c),
    ISCHANGED(maica_cc__Unavailable_To__c)
  )
)

Status Cannot Be Changed Once Approved

Prevents users from changing the Status value once it has been set to Approved.

Validation Rule Detail

Rule Name

VAL_UNAVAILABILITY_0004

Error Message

VAL_0004: Status cannot be changed once it has been set to Approved.

Error Condition Formula
AND(
  ISPICKVAL(PRIORVALUE(maica_cc__Status__c), 'Approved'),
  NOT(ISPICKVAL(maica_cc__Status__c, 'Approved'))
)

Automation

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Support Item Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Unavailability Status

This trigger is designed to manage the status of unavailability records in Maica.

Detail

Load Order

1

Label

UnavailabilityStatus_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the UnavailabilityStatus_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the status setting process for unavailability records.

  • Trigger Conditions:

    • When a new unavailability record (maica__Unavailability__c) is created.

    • When an existing unavailability record is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When an unavailability record is created or updated, the trigger is initialized. The UnavailabilityStatus_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the UnavailabilityStatus_MDTM class.

    • The class methods perform the following steps:

      • Validation: The unavailability data is validated to ensure it is complete and accurate.

      • Status Setting: Based on predefined criteria, the status of unavailability is set or updated for each record, ensuring that it meets all necessary standards and requirements.

      • Update: The unavailability record is updated with the status details, indicating whether it has passed or failed the validation checks.

Trigger Outcome:

Once executed, the trigger ensures that each unavailability record has its status set or updated correctly, according to the logic specified in the handler class. This helps maintain accurate and consistent status data for unavailability records.

Unavailability Appointments

This trigger is designed to manage the appointments related to unavailability records in Maica.

Detail

Load Order

2

Label

UnavailabilityAppointments_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the UnavailabilityAppointments_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the appointment management process for unavailability records.

  • Trigger Conditions:

    • When a new unavailability record (maica__Unavailability__c) is created.

    • When an existing unavailability record is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialization:

    • When an unavailability record is created or updated, the trigger is initialized. The UnavailabilityAppointments_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

  2. Trigger Execution:

    • Upon initialization, the trigger executes the logic defined in the UnavailabilityAppointments_MDTM class.

    • The class methods perform the following steps:

      • Validation: The unavailability data is validated to ensure it is complete and accurate.

      • Appointment Management: Based on the unavailability, related appointments are either created or updated to ensure they reflect the unavailability accurately.

      • Update: The unavailability record is updated with the newly managed appointment data if necessary.

Trigger Outcome:

Once executed, the trigger ensures that each unavailability record has its related appointments managed correctly, according to the logic specified in the handler class. This helps maintain accurate appointment data and ensures that all appointments are in sync with unavailability records.

Maica Timezone Management

This article provides an overview of how Maica manages Timezones across Salesforce records and the Maica Planner

This article provides an overview of how Maica manages timezones across Appointment & Shift records, Appointment & Shift Locations, Salesforce users, and the Planner. Maica is built to ensure Appointments & Shifts are created in the correct local time for service delivery, while still appearing accurately to all users based on their current timezone—supporting remote teams, interstate operations, and national scheduling coordination.


How Timezones Are Initially Set

When creating a new Appointment, the timezone is automatically set based on the Salesforce user’s current browser timezone (e.g. Melbourne).

This occurs on the Basic Details step of the ‘New Appointment’ screen, before a Location is selected.


Timezone Confirmation Prompt (When Selecting a Location)

If a user selects a Location that is in a different timezone from their current one, Maica will detect this and show a confirmation modal.

Example: You are in Melbourne (GMT+10), and select a Location in Perth (GMT+8).

Maica will display:

  • The current Appointment timezone (based on your browser)

  • The timezone of the selected Location

  • A prompt asking whether you’d like to update the Appointment timezone to match the Location

If you click ‘Update’:

  • The Appointment’s timezone will be updated to match the Location (e.g. changed to Australia/Perth)

  • When you return to the Basic Details section, you’ll see the new timezone applied.


What does this mean for Scheduling?

Once the timezone is set (either by default or after confirmation), Maica treats all time inputs as relative to that timezone.

Example:

You are in Melbourne, but the Appointment location is Perth. You schedule the Appointment for 8:00 AM (Perth time).

  • The Appointment is stored as 8:00 AM Australia/Perth

  • On your Planner (in Melbourne), this Appointment will appear at 10:00 AM

  • A user in Perth will see the Appointment at the intended local time of 8:00 AM


How Timezones Are Displayed in Maica

In the Appointment Record

  • The Appointment Time Zone is displayed alongside the scheduled times

  • All internal logic (travel, alerts, shifts) respects this timezone

In the Planner

  • Appointment times are automatically converted and displayed in the viewer’s browser timezone

  • A globe icon appears in the Planner header showing the viewer’s current timezone

  • Tooltip appears on hover: “Your current Time Zone”


Additional Behaviours

  • If you change the Location after setting a timezone, Maica may prompt you again if a mismatch is detected.

  • In border regions, Admins can override and manually select a timezone.

  • For Appointments that span multiple timezones, Maica allows users to choose which timezone to apply.


Summary Table


Example Table

Support Item Configuration

Learn how to configure your Support Items to facilitate the Xero Integration within Maica

How do I configure my Support Items to facilitate the Xero integration?

If you have not already set up your Xero Connection and Webhook, please do so before configuring your Support Items. Click to learn how.

Once you have connected Maica and Xero, you then need to populate your Support Item records to facilitate the integration. This step is crucial in ensuring the integration executed effectively.

So, to get started, head to a Support Item record.

Scroll down to the Xero Information Section, as shown below.

There are three fields related to the Support Item that need to be populated, these include:

Field
Description

For Tax Type, the default value is GST Free Income, you can change this to match your billing processes.

Ensure that these fields are populated for all your Support Items in order to facilitate the Xero Integration within Maica.

Invoice Schema
Invoice Line Item

Layer

What It Controls

How Maica Handles It

Browser/User Timezone

Sets default timezone when creating a new Appointment

Detected automatically via browser (e.g. Melbourne)

Location Timezone

Reflects where the Appointment service occurs

Detected via Google API or manually selected

Appointment Timezone

Stored on the record and used for travel/time logic

Becomes the source of truth for scheduling

Displayed Time

What each user sees on the Planner or record view

Converted automatically to match each user’s browser timezone

Scenario

User Timezone

Appointment Location

Scheduled Time (Local)

What User Sees

User in Melbourne creates an Appointment at 8:00 AM for a Perth Location and clicks Update when prompted

Melbourne (GMT+10)

Perth (GMT+8)

8:00 AM Perth time

10:00 AM (adjusted to Melbourne time)

User in Sydney views an Appointment created by someone in Perth for 2:00 PM Perth time

Sydney (GMT+10)

Perth (GMT+8)

2:00 PM Perth time

4:00 PM (adjusted to Sydney time)

Admin in Brisbane creates Appointment with no Location selected

Brisbane (GMT+10)

None

9:00 AM Brisbane time

9:00 AM

Admin in Adelaide selects a Melbourne Location and clicks Update

Adelaide (GMT+9:30)

Melbourne (GMT+10)

11:00 AM Melbourne time

10:30 AM (adjusted to Adelaide time)

Planner user in Perth views an Appointment scheduled in Melbourne at 1:00 PM

Perth (GMT+8)

Melbourne (GMT+10)

1:00 PM Melbourne time

11:00 AM (adjusted to Perth time)

Xero Invoice Line Description

The description of the Support Item used where it appears on related Invoice Line Item records in Xero. This is the Support Item description that is provided to the customer. If left null, Maica will automatically use the name of the associated Support Item.

Finance Account Code

The Xero General Ledger Account Code, i.e. Income or Revenue, that is applied to the Support Item. This field is used by Maica as part of the Xero integration and determines how the income is treated in your finance system.

Tax Type

The Xero Tax Rate applied to the Support Item from a finance perspective, i.e. GST on Income. This field is used by Maica as part of the Xero integration.

here

NDIS

Learn about NDIS Claim Management Settings in Maica

These settings determine how Maica manages Claiming and its function throughout the application. You can use the Claim Management settings to manage how Payment Requests will be provided to the NDIS for claim processing. For reference:

  • API means Payment Requests will be automatically created and submitted to the NDIS for processing based on the Claim Frequency settings defined below and on the Invoice Entry component.

  • BPR File means Payment Requests will be automatically created but not submitted to the NDIS for processing. In order to submit the Payment Request, you need to generate the Bulk Payment Request (BPR) File via the Generate Bulk Payment Request section below. You can then upload this file via the myplace provider portal.

    • These Payment Request records will be created with Status = BLANK

In addition, and before we dive into configuring your Claim Settings in Maica, please refer to the quick overview of Claim Behaviour between Claim Management Settings vs Invoice Entry Claim, as this can vary depending on where you are in Maica and hence is important to understand. To learn more, see the expandable dropdown below.

Claim Management Settings vs Invoice Entry Claim

Below describes a quick overview of Claim Behaviour between Claim Management Settings vs Invoice Entry Claim within Maica, as this can vary depending on where you are in Maica.

Claim Management - Maica Settings

The Claim Management settings in the Maica Settings tab define your organisation-wide default Claim Settings. These settings act as the default behaviour applied if no changes are made during Invoice Entry (explained below).

Claim Management - Invoice Entry

The Claim Behaviour dropdown in the component allows users to define how a specific Invoice should be claimed (as shown below). These settings are applied on an individual basis and affect only the Invoice being entered. Once the Invoice is submitted, the Claim Behaviour selection resets, ready for the next Invoice. If no Claim Behaviour is selected at the Invoice level, the Global Setting behaviour will apply.

Available Claiming Options

If your Claim Method is set to API, only the following values are available in the Invoice Entry component:

  • Use Claim Settings

  • Claim Immediately

  • Do Not Claim

If your Claim Method is set to BPR File, only the following Claim Behaviour values are available in the Invoice Entry component:

  • Claim via BPR File (default)

  • Do Not Claim

Please refer to the below headings for more information on each setting:

Claim Method

The Claim Method Setting not only allows you to select the Method of Claiming, but also, the Claim Behaviour.

Firstly, for your Claim Method, you can select between API or BPR File (as explained above).

It is important that you do not toggle from BPR File to API with an open, or unfinished, claiming cycle. If you have generated Payment Request records with the Claim Method = BPR, these cannot be claimed via the API.

Then, you can select your Claim Behaviour from the following options:

A Claim Behaviour in Maica determines how Payment Requests are managed, created, and submitted to the NDIS for processing. It allows you to control the way claims are handled based on your organisation's workflow requirements.

Claim Behaviour
Description
Claim Method

Use Claim Settings

The default option that uses the Claim Frequency settings configured in Maica. Claims will be created and submitted based on these predefined rules. To learn more Claim Frequency, see below.

API

Claim Immediately

Payment Requests are created and submitted to the NDIS as soon as they are generated

API

Do Not Claim

Prevents a Payment Request from being submitted for claiming.

API, BPR

Claim via BPR File

Payment Requests are generated and included in a , which can be manually uploaded to the myplace provider portal for processing.

BPR

Claim via HCP File

Payment Requests are generated and included in an HCP (Home Care Package) File, suitable for claims processed under the HCP framework.

Generate Bulk Payment Request (BPR) File

With Maica, you can generate a Bulk Payment Request (BPR) File and upload it directly to the myplace Provider Portal.

The BPR file allows you to submit multiple payment requests in a single upload, saving time compared to submitting individual requests for each Service Booking or Participant.

Once the Bulk Payment Request file is generated in Maica:

  1. Log in to the myplace Provider Portal.

  2. Navigate to the Bulk Payment Request Upload section.

  3. Upload the file generated by Maica.

Maica ensures the file is fully compliant with the NDIS template, so you can confidently upload it without any manual adjustments.

Before you generate and use a Bulk Payment Request (BPR) File, it's important to understand the BPR process and its steps. The process consists of three sequential steps that must be completed in the order shown. These steps are outlined in the expandable box below.

Overview of the Bulk Payment Request (BPR) Process

Step 1: Bulk Payment Request (BPR) File

The Request File is the initial file generated in Maica (from Salesforce) that contains the Payment Request data you intend to submit to PRODA for processing. The below text details how to generate the Request File within Maica.


Step 2: Bulk Payment Request Results (BPR) File

The Results File is downloaded from PRODA after uploading your Request File (Step 1). It contains the outcome (Success/Fail) for each Payment Request included in your submission.

Note: While the BPR Results File includes payment information, Maica does not use this file to update payment request statuses. Instead, the Remittance File (Step 3) is used for that purpose.


Step 3: Bulk Payment Request Remittance (BPR) File

The Remittance File is downloaded from PRODA and contains the final payment results for each Payment Request included in your original upload (Step 1).

Now that you have an overview of the BPR process, continue to the section below to learn how to generate the Bulk Payment Request (BPR) File from Maica and Salesforce.

Generating a Bulk Payment Request (BPR) File

So, once you're in the Claim Management section of Maica Settings, generating the Bulk Payment Request (BPR) File is just a few clicks away.

Generate Bulk Payment Request in Maica Settings

Before you click Generate CSV button shown above, you’ll need to complete a one-time setup to enter your Registration Number. This is the number listed as your Organisation ID in your Provider Portal Profile. Input your Registration Number in the Registration Number field shown above.

Once done, apply the relevant filters:

  1. Date Range

    • Note, the Date Range filter uses the Invoice Created Date. Maica will search for all Invoice records added to Salesforce within the Start Date and End Date specified.

  2. Payment Request Status

    • You can filter by the following Payment Request Status values:

      • Blank

      • Failed

      • Incomplete

      • Cancelled

      • Rejected

We recommend always including the Blank value. This ensures all records within the selected Date Range that have not been included in a previous BPR file are captured. The other values (Failed, Incomplete, Cancelled, Rejected) allow you to retry or reclaim previously unsuccessful Payment Requests.

Then, use the Exclude option to specify Providers or Invoices you do not want included in the BPR File. Any items listed here will be excluded from the CSV file generated. The Exclude Section is shown below.

Once your filters are applied:

  1. Maica will display a count of all Payment Request records that match your criteria.

  2. Review the total displayed to confirm it meets your expectations.

  3. Click Generate CSV, and Maica will handle the rest!

What Happens Next?

During the file generation process, Maica performs a series of important updates. For more information, refer to the Post BPR File Generation section below.

Please note, the myplace Provider Portal only supports up to 5000 rows in an uploaded BPR File, meaning, if your filter criteria returns a result set containing more than 5000 rows, Maica will present the error below and not allow you to complete the process. The following error will be displayed:

The results of the date range and status criteria selected exceeds 5000 records. Please adjust your criteria to refine the results.

BPR File Query Summary

How Does Maica Determine What to Include in the BPR File? Maica determines which Payment Request records to include in the BPR file based on the following criteria:

  1. Payment Request Status

    • Only records matching the value(s) selected in the Status Filter will be included.

  2. Invoice Created Date

    • Records with an Invoice Created Date that falls within the Start Date and End Date specified in the filters will be included.

For a more technical user:

SELECT Id FROM maica_cc__Payment_Request__c
WHERE DAY_ONLY(maica_cc__Invoice_Line_Item__r.maica_cc__Invoice__r.CreatedDate) >= :startDate
AND DAY_ONLY(maica_cc__Invoice_Line_Item__r.maica_cc__Invoice__r.CreatedDate) <= :endDate
AND maica_cc__Status__c IN :selectedStatuses

For more details on applying these filters, see the section above.

Post BPR File Generation

Once the Bulk Payment Request (BPR) File has been generated, Maica performs specific actions to complete this first step in the BPR Claiming process. These actions are outlined below:

New Payment Request Created (Reclaimed Payment Requests)

When generating the BPR File, if the Status Filter included a value other than Blank, this indicates that a previous claim attempt has already been made—either through a BPR File or the API. In this case, a new Payment Request record is required to facilitate the new claim.

This is because PRODA requires each Payment Request to have a unique Claim Reference. A Payment Request can only be used once, so to attempt the claim again (a “reclaim”), Maica creates a new Payment Request record.

Here’s what happens:

  • The previously attempted Payment Request record is cloned, and a new Payment Request record is created.

  • The Status of the new record will be updated to Awaiting Approval, regardless of the previous status.

  • The Status of the original (cloned) Payment Request record is updated to Resubmitted to reflect that it has been included in a new BPR File.

The Resubmitted Status value is only used when the Claim Method = BPR File.

Payment Request Updates - Field Updates

After the Bulk Payment Request (BPR) File is exported, Maica updates specific fields on the Payment Request records included in the file.

Payment Request Field
Value

Status

Awaiting Approval ()

Claimed Amount

Invoice Line Item.Claim Balance

Claim Date

TODAY

NDIS Reference

Claim Reference Index ()

Payment Request Updates - Status

To ensure that the Payment Request reflects its inclusion in the BPR File, Maica updates the Status of the Payment Request record(s) to Awaiting Approval.

The next update to the Payment Request Status will occur when the BPR Results File is imported.

Payment Request Update Claim Reference Index

As part of the BPR File export, Maica ensures consistency across fields by setting the NDIS Reference field to match the Claim Reference Index field.

This ensures that the NDIS Reference field is populated consistently, whether you are claiming via the API or the BPR File.

When claiming via the API, the Claim Reference is not used, as the NDIS does not require this value. Instead, PRODA returns an API Reference, which Maica populates in the NDIS Reference field.

BPR File Template Definition

Template Field Name
Information

RegistrationNumber

The Provider's registration number as entered in Maica Settings

NDISNumber

Participant's NDIS Number on the Contact

SupportsDeliveredFrom

Service Date on the Invoice Line Item

SupportsDeliveredTo

Service Date on the Invoice Line Item

SupportNumber

Support Item Number of the Product provided on the Invoice Line Item

ClaimReference

Claim Reference on the Invoice Line Item

Quantity

Quantity on the Invoice Line Item See note below for additional details.

Hours

Since Quantity is entered, this field is not required.

UnitPrice

Unit Price on the Invoice Line Item

GSTCode

GST Code on the Invoice Line Item GST as applicable to the item or service. P1 = Tax Claimable (10%) P2 = GST Free P5 = GST out of Scope

AuthorisedBy

Legacy field, can be left blank

ParticipantApproved

Legacy field, can be left blank

InKindFundingProgram

Not Applicable

ClaimType

Claim Type on the Invoice Line Item Claim type of the service provided - “(Blank)” – Direct Service. You must leave field blank. - CANC: Cancellation - REPW: NDIA Required Report - TRAN: Provider Travel - NF2F: Non-Face-to Face Services

CancellationReason

Cancellation Reason on the Invoice Line Item Reason of the cancellation type - NSDH: No show due to health reasons - NSDF: No show due to family issues - NSDT: No show due to unavailability of transport - NSDO: Other

Quantity Logic

In a reclaim scenario (e.g., an additional claiming attempt), the Quantity value populated in the BPR File may differ from the initial claiming attempt. The logic is summarised below:


When the following condition is met:

  • Payment Request.Claimed Amount > Invoice Line Item.Unit Price

Maica sets:

  • BPR Quantity = Claimed Amount ÷ Unit Price

  • BPR UnitPrice = Unit Price


Otherwise, Maica sets:

  • BPR Quantity = 1

  • BPR UnitPrice = Claimed Amount

This ensures that the UnitPrice does not exceed the Price Book price, as this would result in rejection by PRODA.

Sample BPR File

Below shows a sample BPR File that has been generated.

For further assistance with processing bulk requests in the myplace Provider Portal once you have the BPR File, refer to this page or watch this video tutorial by the NDIS.

Bulk Payment Request (BPR) File
detail below
detail below

Service Agreement

The Service Agreement object in Maica represents the details of a Service Agreement signed between your organisation and a Client.

Fields & Relationships

The table below provides a comprehensive overview of all fields and relationships for the Service Agreement object in Maica. Please refer to the table below for detailed information.

Click here to view and download the complete Service Agreement Schema.

Validation Rules

The list below outlines the Validation Rules applied to the Service Agreement Object in Maica.

Please refer to the list below for more detailed information on each Validation Rule.

Funding Administrator Required for Non-Self Funded Sources

Ensures that the Funding Administrator lookup is populated when the Funding Source is any value other than Self-Funded. Not required for Self and Agency Managed in the NDIS.

Validation Rule Detail

Rule Name

VAL_SERVICE_AGREEMENT_0001

Error Message

VAL_0001: Please provide the Funding Administrator.

Error Location

Funding Administrator

Error Condition Formula
AND(
  ISBLANK(maica_cc__Funding_Administrator__c),
  NOT(
    OR(
      ISPICKVAL(maica_cc__Funding_Source__c, 'Self Funded'),
      AND(
        ISPICKVAL(maica_cc__Funding_Source__c, 'NDIS'),
        ISPICKVAL(maica_cc__Funding_Type__c, 'Self Managed')
      ),
      AND(
        ISPICKVAL(maica_cc__Funding_Source__c, 'NDIS'),
        ISPICKVAL(maica_cc__Funding_Type__c, 'Agency Managed')
      )
    )
  )
)

Agreement Start Date Must Be Before End Date

Ensures that the Agreement's Start Date cannot be after the End Date.

Validation Rule Detail

Rule Name

VAL_SERVICE_AGREEMENT_0002

Error Message

VAL_0002: The Start Date cannot be after the End Date.

Error Location

Start Date

Error Condition Formula
maica_cc__Start_Date__c  >  maica_cc__End_Date__c

Start and End Dates Required for NDIS Funding Source

Ensures the Start and End Date are provided when the Funding Source is NDIS.

Validation Rule Detail

Rule Name

VAL_SERVICE_AGREEMENT_0003

Error Message

VAL_0003: As the Funding Source is NDIS, the Start and End Date are required.

Error Location

Top of Page

Error Condition Formula
AND(
  ISPICKVAL(maica_cc__Funding_Source__c, 'NDIS'),
  OR(
    ISBLANK(maica_cc__Start_Date__c),
    ISBLANK(maica_cc__End_Date__c)
  )
)

Price List Must Be Associated

Ensures that the Price List is populated.

Validation Rule Detail

Rule Name

VAL_SERVICE_AGREEMENT_0004

Error Message

VAL_0004: Please associate a Price List.

Error Location

Price List

Error Condition Formula
ISBLANK(maica_cc__Price_List__c)

Price List and Service Agreement Date Alignment

Ensures that the associated Price List Start Date is less than or equal to the Service Agreement Start Date and the Price List End Date is greater than the Service Agreement Start Date.

Validation Rule Detail

Rule Name

VAL_SERVICE_AGREEMENT_0005

Error Message

VAL_0005: The Price List Start Date must be less than or equal to the Service Agreement Start Date and the Price List End Date must be greater than the Service Agreement Start Date.

Error Location

Price List

Error Condition Formula
AND(
  maica_cc__Price_List__r.maica_cc__Start_Date__c <= maica_cc__Start_Date__c,
  maica_cc__Price_List__r.maica_cc__End_Date__c > maica_cc__Start_Date__c
)

Automation

Flows

The list below outlines the Flows applied to the Service Agreement Object in Maica.

Please refer to the list below for more detailed information on each Flow.

Cancel Service Agreement

This flow is designed to manage the cancellation of a service agreement. It ensures that service agreements can only be canceled if they are active, providing confirmation screens for user actions and handling any errors that may occur during the process.

Flow Detail

Flow Label

Maica - Cancel Service Agreement

API Name

maica__Cancel_Service_Agreement

Type

Screen Flow

Flow Summary

This flow facilitates the cancellation process for service agreements by following these steps:

  • Checking the status of the service agreement.

  • Confirming the cancellation with the user.

  • Setting the service agreement as cancelled.

  • Updating the service agreement record.

  • Displaying appropriate messages based on the outcome of the process.

Flow Description
  1. Start (Screen Flow):

    • The flow is initiated.

  2. Get Current Service Agreement (Get Records):

    • The flow retrieves the current Service Agreement record based on the recordId provided.

    • If the record retrieval fails, the flow handles the error through the Handle_Error assignment.

  3. Service Agreement With Active Status? (Decision):

    • The flow checks if the retrieved Service Agreement has an active status.

    • Yes: If the Service Agreement is active, the flow proceeds to the Cancel Service Agreement screen.

    • No: If the Service Agreement is not active, the flow displays the Service Agreement Not Active screen and ends.

  4. Cancel Service Agreement (Screen):

    • The flow displays a confirmation screen for canceling the Service Agreement, showing the participant's name and a note that active service bookings with PRODA are not impacted.

    • Upon confirmation, the flow moves to the next step.

  5. Set Service Agreement Is Cancelled To True (Assignment):

    • The flow sets the Is_Cancelled__c field of the Service Agreement to true.

    • It then proceeds to update the Service Agreement record.

  6. Update Service Agreement (Update Records):

    • The flow updates the Service Agreement record with the new status.

    • If the update operation fails, the flow handles the error through the Handle_Error assignment.

  7. Finish Cancel Service Agreement (Screen):

    • The flow displays a screen indicating the successful cancellation of the Service Agreement.

    • The flow then ends.

  8. Service Agreement Not Active (Screen):

    • If the Service Agreement is not active, the flow displays a screen indicating that the agreement is not active and cannot be canceled.

    • The flow then ends.

  9. Handle Error (Assignment):

    • If any errors occur during the process (such as during record retrieval or updating), the flow captures the error message in the FlowFaultMessage variable and ends.

Discharge Service Agreement Screen Flow

This flow is designed to handle the discharge process for Service Agreements. It ensures a smooth and efficient discharge process with appropriate error handling and user guidance.

Flow Detail

Flow Label

Maica - Discharge Service Agreement Screen Flow

API Name

maica__Maica_Discharge_Service_Agreement_Screen_Flow

Type

Screen Flow

Flow Summary

This flow facilitates the discharge process for Service Agreements by following these steps:

  • Displaying instructions for discharging a Service Agreement.

  • Calling a subflow to generate a discharge statement.

  • Checking for any fault messages from the subflow.

  • Updating the Service Agreement record with discharge details.

  • Displaying success or error messages based on the outcome of the process.

Flow Description
  1. Start (Screen Flow):

    • The flow is initiated.

  2. Discharge Service Agreement (Screen):

    • Displays instructions to the user, prompting them to proceed with the discharge process by selecting "Next".

    • Connects to the Call_Generate_Discharge_Statement_Flow subflow.

  3. Call Generate Discharge Statement Flow (Subflow):

    • Triggers the subflow Maica_Generate_Discharge_Statement to generate a discharge statement for the service agreement.

    • If the subflow sets the FlowFaultMessage, the flow proceeds to the Discharge_Failed screen.

    • If the FlowFaultMessage is not set, the flow proceeds to the Discharge_Complete screen.

  4. Flow Fault Message Set? (Decision):

    • Checks if the FlowFaultMessage is set.

    • Flow Fault Message Set: If the FlowFaultMessage is set, the flow proceeds to the Discharge_Failed screen.

    • Default Outcome: If the FlowFaultMessage is not set, the flow proceeds to the Discharge_Complete screen.

  5. Discharge Complete (Screen):

    • Displays a success message indicating that the service agreement has been successfully discharged and the discharge statement has been generated.

    • Connects to the UPDATE_Service_Agreement record update.

  6. Service Agreement (Update Records):

    • Updates the service agreement record to set the Discharged__c field to true and the Discharge_Date__c to the current date.

    • If the update operation fails, the flow handles the error through the Handle_Error assignment.

  7. Discharge Failed (Screen):

    • Displays an error message indicating that the discharge process has failed, along with the fault message.

    • Ends the flow.

Generate Discharge Statement

This flow generates Statement for period of the claim to the discharge date, then generates the Discharge Statement record.

Flow Detail

Flow Label

Maica - Generate Discharge Statement

API Name

maica__Maica_Generate_Discharge_Statement

Type

Autolaunched

Flow Summary

This flow ensures that a discharge statement is accurately generated based on the service agreement and its related monthly statements.

  • Starts on service agreement creation or update.

  • Retrieves and validates the service agreement.

  • Assigns statement period dates and calls a subflow to generate service agreement statements.

  • Loops through monthly statements and updates discharge statement counters.

  • Creates the discharge statement and updates the service agreement.

Flow Description
  1. Start (Record-Triggered Flow):

    • The flow begins when a service agreement is created or updated.

  2. Get Service Agreement (Get Records):

    • Retrieves the service agreement based on the provided Service Agreement Id.

  3. Validate Not Discharged (Decision):

    • Checks if the service agreement is not already discharged:

      • If not discharged, it proceeds to assign the statement period date values.

      • If discharged, it assigns a fault message indicating the service agreement is already discharged.

  4. Assign Statement Period Date Values (Assignment):

    • Sets the claim period start date to the first day of the current month.

    • Sets the claim period end date to the current date.

  5. Call Generate Service Agreement Statements Flow (Subflow):

    • Calls another flow to generate service agreement statements for the specified period.

  6. Decision Flow Fault Message (Decision):

    • Checks if a fault message is set:

      • If a fault message is set, it assigns the fault message.

      • If no fault message is set, it proceeds to get the monthly statements.

  7. Get Monthly Statements (Get Records):

    • Retrieves monthly statements related to the service agreement.

  8. Loop Through Monthly Statements (Loop):

    • Iterates over the retrieved monthly statements:

      • For each statement, it adds the values to the discharge statement counters.

  9. Assign Counters (Assignment):

    • Updates the discharge statement counters by adding values from the monthly statements:

      • Lifetime Billable Fees

      • Lifetime Claimable Expenditure

      • Lifetime Claimable Fees

      • Lifetime Client Contributions

      • Lifetime Subsidy Supplement Income

  10. Assign Discharge Statement Values (Assignment):

    • Sets the discharge statement values:

      • Issue Date

      • Period Start Date

      • Period End Date

      • Status

      • Type

  11. Create Discharge Statement (Create Records):

    • Creates the discharge statement record.

  12. Assign Service Agreement Values (Assignment):

    • Updates the service agreement to set the discharge date and mark it as discharged.

Service Agreement Fee Invoicing Initialisation

Fee Invoicing Step 1

This flow is designed to schedule the initialisation of the invoicing process for service agreements, setting their status to "Initialised" to trigger the fee invoicing flow. By automating this process, the flow ensures that service agreements are ready for fee invoicing without manual intervention.

Flow Detail

Flow Label

Maica - Service Agreement - Fee Invoicing Initialisation

API Name

maica___Service_Agreement_Fee_Invoicing_Initialisation

Type

Autolaunched

Flow Summary

This flow ensures that the invoicing process for service agreements is initialised on a daily basis by:

  • Running the flow daily at a specified time.

  • Filtering service agreements based on their status and funding type.

  • Updating the invoicing flow status to "Initialised" to trigger the fee invoicing flow.

Flow Description
  1. Start (Scheduled Flow):

    • The flow is initiated on a daily schedule at 00:15 UTC.

    • Retrieves service agreements with specific conditions:

      • Status__c is "Active" or "On Leave".

      • Funding_Type__c is "Home Care Package".

  2. Update Service Agreement (Update Records):

    • Updates the Invoicing_Flow_Status__c field of the retrieved service agreements to "Initialised".

Service Agreement Fee Invoice Trigger

Fee Invoicing Step 2

This flow is designed to trigger the generation of fee invoices and their line items for service agreements. It ensures a streamlined and automated process for generating fee invoices for service agreements, with appropriate error handling and logging mechanisms.

Flow Detail

Flow Label

Maica - Service Agreement - Fee Invoice Trigger

API Name

maica__Maica_Service_Agreement_Fee_Invoice_Trigger

Type

Autolaunched

Flow Summary

This flow facilitates the generation of invoices and line items for service agreement fees by:

  • Detecting changes to the invoicing flow status.

  • Retrieving the relevant service agreement record.

  • Triggering the Fee Invoice Generation Flow to create invoices and line items.

  • Updating the service agreement status to complete.

Flow Description
  1. Start (Auto-Triggered Flow):

    • The flow is initiated, starting with the detection of changes to the Invoicing_Flow_Status__c field.

  2. Get Service Agreement (Record Lookup):

    • Retrieves the service agreement record where Invoicing_Flow_Status__c is Initialised and Funding_Type__c is Home Care Package.

    • Proceeds to trigger the Fee Invoice Generation Flow.

  3. Trigger Fee Invoice Generation Flow (Subflow):

    • Triggers the subflow Maica_Service_Agreement_Fee_Invoice_Generation_Autolaunch to generate invoices and line items for the service agreement.

    • Passes the recordId of the service agreement and the Processing_Date.

    • Captures any fault message.

    • Proceeds to the DECISION_Flow_Fault decision.

  4. Flow Fault? (Decision):

    • Checks if the FlowFaultMessage is set.

    • If the FlowFaultMessage is set, the flow proceeds to the CREATE_Log step.

    • If the FlowFaultMessage is not set, the flow proceeds to the UPDATE_Service_Agreement step.

  5. Update Service Agreement (Update Records):

    • Updates the service agreement record to set the Invoicing_Flow_Status__c field to Complete.

    • Ends the flow.

  6. Create Log (Record Create):

    • Creates a log record to capture the details of the error.

    • Captures the FlowFaultMessage and other relevant details.

    • Proceeds to update the service agreement status to Failed.

  7. Update Service Agreement to Failed (Update Records):

    • Updates the service agreement record to set the Invoicing_Flow_Status__c field to Failed.

    • Ends the flow.

Service Agreement Fee Invoice Generation

Fee Invoicing Step 3

This flow automates the process of generating fee invoice line items for service agreements. It ensures a streamlined and automated process for generating accurate fee invoices and their associated line items based on the service agreement details.

Flow Detail

Flow Label

Maica - Service Agreement - Fee Invoice Generation (Autolaunch)

API Name

maica__Maica_Service_Agreement_Fee_Invoice_Generation_Autolaunch

Type

Autolaunched

Flow Summary

This flow facilitates the generation of fee invoice line items for service agreements by following these steps:

  • Starting the flow and retrieving the service agreement.

  • Retrieving the related plan and service agreement leave records.

  • Checking if the service agreement is on leave and handling accordingly.

  • Retrieving and validating the income-tested fee plan budget.

  • Assigning the income-tested fee rate and adding the budget to the collection.

  • Checking the type of leave and retrieving the corresponding billable plan budgets.

  • Validating the existence of billable and claimable plan budgets.

  • Calling the Invoice Invocable actions to create copayment and claim invoices.

  • Looping through the billable and claimable plan budgets to assign invoice line item values.

  • Creating the invoice line items.

  • Handling errors during the process.

Flow Description
  1. Start (Auto-Triggered Flow):

    • The flow is initiated, starting with the retrieval of the service agreement.

  2. Get Service Agreement (Record Lookup):

    • Retrieves the service agreement record where the Id matches Service_Agreement_Id.

    • Proceeds to retrieve the related plan.

    • If the record retrieval fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  3. Get Plan (Record Lookup):

    • Retrieves the plan record associated with the service agreement's NDIS Plan.

    • Proceeds to retrieve the service agreement leave.

    • If retrieval fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  4. Get Service Agreement Leave (Record Lookup):

    • Retrieves the service agreement leave record associated with the service agreement.

    • Moves to the decision step to check if the service agreement is on leave.

    • If retrieval fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  5. Service Agreement On Leave? (Decision):

    • Checks if the service agreement leave record is not null.

    • If on leave, proceeds to get the income tested fee plan budget.

    • If not on leave, proceeds to get all billable plan budgets.

  6. Get Income Tested Fee Plan Budget (Record Lookup):

    • Retrieves the income tested fee plan budget associated with the service agreement's NDIS Plan.

    • Proceeds to the decision step for consecutive leave days.

    • If retrieval fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  7. Consecutive Leave Days? (Decision):

    • Checks the consecutive leave days and the applicability of the income tested fee.

    • If consecutive leave days > 28 and income tested fee applicable, proceeds to get the basic subsidy plan budget.

    • If less than 28 days or not applicable, proceeds to assign income tested fee plan budget to the collection.

  8. Get Basic Subsidy Plan Budget (Record Lookup):

    • Retrieves the basic subsidy plan budget associated with the service agreement's NDIS Plan.

    • Proceeds to the decision step for income tested fee rate.

    • If retrieval fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  9. Income Tested Fee Rate? (Decision):

    • Checks if the income tested fee rate is greater than 25% subsidy rate.

    • If true, proceeds to assign income tested fee rate.

    • Proceeds to the next decision step for leave type.

  10. Assign Income Tested Fee Rate (Assignment):

    • Assigns the adjusted income tested fee rate to the income tested fee plan budget.

    • Proceeds to assign the income tested fee plan budget to the collection.

  11. Assign Income Tested Fee Plan Budget to Collection (Assignment):

    • Adds the income tested fee plan budget to the collection of billable plan budgets.

    • Proceeds to the decision step for leave type.

  12. Leave Type? (Decision):

    • Checks the leave type of the service agreement.

    • Proceeds to get billable plan budgets excluding income tested fee if leave type is Hospital or Social.

    • Proceeds to get billable plan budgets excluding income tested fee and basic daily fee if leave type is Respite or Transition.

  13. Get Billable Plan Budgets Excluding Income Tested Fee (Record Lookup):

    • Retrieves the billable plan budgets excluding income tested fee associated with the service agreement's NDIS Plan.

    • Proceeds to validate the billable plan budgets.

    • If retrieval fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  14. Get Billable Plan Budgets Excluding Income Tested Fee and Basic Daily Fee (Record Lookup):

    • Retrieves the billable plan budgets excluding income tested fee and basic daily fee associated with the service agreement's NDIS Plan.

    • Proceeds to validate the billable plan budgets.

    • If retrieval fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  15. Get All Billable Plan Budgets (Record Lookup):

    • Retrieves all billable plan budgets.

    • Proceeds to validate the billable plan budgets.

    • If retrieval fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  16. Validate Billable Plan Budgets? (Decision):

    • Checks if billable plan budgets exist.

    • If true, proceeds to call invoice invocable for copayment.

    • Proceeds to validate the claimable plan budgets if billable plan budgets do not exist.

  17. Call Invoice Invocable (Apex Action):

    • Calls the apex invocable method to get the copayment invoice.

    • Passes parameters like allowDML, fundingType, isCopayment, participantId, and serviceProviderId.

    • Captures the copayment invoice.

    • Proceeds to loop through the billable plan budgets.

    • If the action fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  18. Loop Billable Plan Budgets (Loop):

    • Iterates through each billable plan budget.

    • Proceeds to assign invoice line item values.

    • Proceeds to validate the claimable plan budgets if no more values.

  19. Assign Invoice Line Item Values (Assignment):

    • Assigns values to the invoice line item from the current billable plan budget in the loop.

    • Proceeds to add the invoice line item to the collection.

  20. Assign Invoice Line Item to Collection (Assignment):

    • Adds the invoice line item to the collection of invoice line items.

    • Proceeds to the next iteration of the loop.

  21. Validate Claimable Plan Budgets? (Decision):

    • Checks if claimable plan budgets exist.

    • If true, proceeds to call invoice invocable for claim.

    • Proceeds to create invoice line items if claimable plan budgets do not exist.

  22. Call Invoice Invocable (Apex Action):

    • Calls the apex invocable method to get the claim invoice.

    • Passes parameters like allowDML, fundingType, isCopayment, participantId, and serviceProviderId.

    • Captures the claim invoice.

    • Proceeds to loop through the claimable plan budgets.

    • If the action fails, the flow handles the error through the ASSIGN_Flow_Fault_Message assignment.

  23. Loop Claimable Plan Budgets (Loop):

    • Iterates through each claimable plan budget.

    • Proceeds to assign invoice line item values.

    • Proceeds to create invoice line items if no more values.

  24. Assign Invoice Line Item Values (Assignment):

    • Assigns values to the invoice line item from the current claimable plan budget in the loop.

    • Proceeds to add the invoice line item to the collection.

  25. Assign Invoice Line Item to Collection (Assignment):

    • Adds the invoice line item to the collection of invoice line items.

    • Proceeds to the next iteration of the loop.

  26. Create Invoice Line Items (Create Records):

    • Creates invoice line items from the collection of invoice line items.

    • Completes the creation and ends the flow.

    • If an error occurs during creation, it moves to the error handling step.

  27. Assign Flow Fault Message (Assignment):

    • Assigns the flow fault message to the FlowFaultMessage variable in case of errors.

Trigger Handlers

The list below outlines the Trigger Handlers applied to the Service Agreement Object in Maica.

Please refer to the list below for more detailed information on each Trigger Handler.

Service Agreement Price List

This trigger is designed to ensure that the correct price list is applied to service agreements in Maica.

Detail

Load Order

1

Label

ServiceAgreementPriceList_MDTM

Execution, Logic & Outcome

Trigger Execution

The trigger logic defined in the ServiceAgreementPriceList_MDTM class is executed when the trigger conditions are met.

  • Trigger Conditions:

    • When a new service agreement (maica__Service_Agreement__c) is created.

    • When an existing service agreement is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a service agreement record is created or updated, the trigger is initialised. The ServiceAgreementPriceList_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ServiceAgreementPriceList_MDTM class.

    • The class methods perform the following steps:

      • Validation: The service agreement data is validated to ensure it meets the criteria required for applying a price list.

      • Determination: The appropriate price list is determined based on predefined criteria such as the type of service and the client category.

      • Application: The correct price list is then applied to the service agreement record.

Trigger Outcome:

After the price list application logic is executed, the service agreement record is saved with the associated price list. The outcome is a consistent and accurate application of price lists to service agreements, ensuring proper billing and management of services.

Service Agreement Name Formatting

This trigger is designed to ensure that the service agreement names are formatted correctly in Maica.

Detail

Load Order

1

Label

ServiceAgreementNameFormatting_MDTM

Execution, Logic & Outcome

Trigger Execution

The trigger logic defined in the ServiceAgreementNameFormatting_MDTM class is executed when the trigger conditions are met.

  • Trigger Conditions:

    • When a new service agreement (maica__Service_Agreement__c) is created.

    • When an existing service agreement is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a service agreement record is created or updated, the trigger is initialised. The ServiceAgreementNameFormatting_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 1.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ServiceAgreementNameFormatting_MDTM class.

    • The class methods perform the following steps:

      • Validation: The current name format of the service agreement is validated to check if it meets the predefined formatting criteria.

      • Formatting: If the name does not meet the criteria, the appropriate formatting rules are applied. This may include adding standard prefixes, suffixes, or adjusting the structure of the name.

Trigger Outcome:

After the name formatting logic is applied, the service agreement record is saved with the newly formatted name. The outcome is a consistent and standardised format for all service agreement names, which helps maintain uniformity and clarity across records.

Service Agreement Validation

This trigger is designed to manage the validation of service agreements in Maica.

Detail

Load Order

2

Label

ServiceAgreementValidation_MDTM

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the ServiceAgreementValidation_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the validation process for service agreements.

  • Trigger Conditions:

    • When a new service agreement (maica__Service_Agreement__c) is created.

    • When an existing service agreement is updated.

    • Any specific field changes that are monitored by the trigger (defined in the handler class).

Logic Explanation

  1. Initialisation:

    • When a service agreement record is created or updated, the trigger is initialised. The ServiceAgreementValidation_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

  2. Trigger Execution:

    • Upon initialisation, the trigger executes the logic defined in the ServiceAgreementValidation_MDTM class.

    • The class methods perform the following steps:

      • Validation: The service agreement data is validated to ensure it is complete and accurate.

      • Check: The data is checked for completeness and accuracy based on predefined criteria such as required fields and logical consistency.

      • Update: The service agreement record is updated with the results of the validation, including any errors or warnings.

Trigger Outcome:

Once executed, the trigger ensures that each service agreement is validated correctly, based on the logic defined in the handler class. This helps maintain accurate and complete data for service agreements.

Unavailability Schema
Appointment Service
Support Item
Support Category
Appointment Breaks
Connection
Connections
Manage Budget
Manage Budget
here
Price List
Manage Budget
here
Invoice
Service Agreement Schema