1 of 72

Admin Guide

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

Getting Started

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 contact us to assist with the migration of this.

To check your hosting for Saleforce, follow the steps outlined below:

Log into your Salesforce instance
Go to Setup
Type Company Information
Check the Instance value
Go to https://availability.salesforce.com/find-my-instance/
Copy & Paste the Instance value to see where your instance is located

Data

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:

Fields & Relationships
Validation Rules
Flows
Trigger Handlers

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.

TO BE FILLED

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.

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.

Automation

Trigger Handlers

The table below outlines the Trigger Handlers applied to the Agreement Item Object in Maica and their 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.

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

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).
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.

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

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).
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.

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

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).
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.

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

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).
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.

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.

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.

Check out Date/Time Must Be After Check in Date/Time

The checkout date/time must be greater than the checkin date/time.

Cancellation Date Required When Cancellation Reason is Set

If the cancellation reason is set, then a cancellation date must be supplied.

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 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

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.
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.
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.
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.

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.

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

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).
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.

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

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).
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.

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

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).
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.

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

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).
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.

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

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).
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.

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 here to view and download the complete Availability Schema.

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 here to view and download the complete Booking Item Schema.

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.

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.

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.

This rule is to ensure that the Connection Related Contact has an Email address when Invoice Recipient and/or Statement Recipient = TRUE

Error Condition Formula

AND(
OR(
maica_cc__Statement_Recipient__c,
maica_cc__Invoice_Recipient__c
),
ISBLANK(maica_cc__Related_Contact__r.Email)
)

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.

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 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

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.
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.
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.
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.

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

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).
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.

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

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).
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.

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.

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

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).
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.

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

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).
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.

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.

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.

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.

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 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

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.
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.
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.
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.
Set Plan Participant Owner Id (Assignment):
- Assigns the participant owner's ID to UserIdToSendEmail.
- Proceeds to send the email.
Set User Id (Assignment):
- Assigns the user ID from the email setting to UserIdToSendEmail.
- Proceeds to send the email.
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.

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

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).
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.

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.

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 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

Start (Record-Triggered Flow):
- Triggered when the Effective Date, End Date, or Is Active field is changed.
Calculate Is Active Status (Formula):
- Determines if the Funding Item is currently active based on the Effective Date, End Date, and current date.
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

Start (Record-Triggered Flow):
- Triggered before inserting or updating a Funding Item record.
Calculate Unit of Measurement (Formula):
- Converts the Unit of Measurement from the related Product record to text.
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.

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.

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.

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 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

Start (Record-Triggered Flow):
- Object: Invoice__c
- Trigger: When the invoice record is updated or created.
- Input Variable: recordId
Get Invoice (Record Lookup):
- Filters: Retrieves the invoice record where the Id matches recordId.
- Connector: Proceeds to check the invoice status.
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.
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.
Set Invoice Cancelled (Assignment):
- Sets the Cancelled__c field of the invoice to true.
- Connector: Proceeds to update the invoice.
Update Invoice (Record Update):
- Updates the invoice record with the cancelled status.
- Connector: Proceeds to display the "Invoice Cancelled" screen.
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 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

Start (Record-Triggered Flow):
- The flow begins when an invoice is created or updated.
- It is triggered before the record is saved.
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.
Set Cancelled (Assignment):
- Sets the invoice status to "Cancelled".
Set Not Paid Status (Assignment):
- Sets the invoice status to "Not Paid".
Set Partially Paid Status (Assignment):
- Sets the invoice status to "Partially Paid".
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.

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.

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

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).
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.

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).

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).
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.

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

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).
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.

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

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).
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.

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

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).
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.

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.

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 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

Start (Record-Triggered Flow):
- The flow begins when an invoice line item is created or updated.
- It is triggered before the record is saved.
Set Line Total and GST (Assignment):
- Calculates and assigns the line total, GST amount, and amount for the invoice line item.
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".
Set Entered Status (Assignment):
- Sets the invoice line item status to "Entered".
Set Claimed Status (Assignment):
- Sets the invoice line item status to "Claimed".
Set Fully Paid Status (Assignment):
- Sets the invoice line item status to "Fully Paid".
Set Partially Paid Status (Assignment):
- Sets the invoice line item status to "Partially Paid".
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.

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

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).
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.

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

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).
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.

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.

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 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

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.
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.
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.
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.

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

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).
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.

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.

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.

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.

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

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).
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.

Payment Request Initialise ABA Export

This trigger is designed to initialise the ABA export for payment requests in Maica.

Execution, Logic & Outcome

Execution of Trigger Logic:

The trigger logic defined in the PaymentRequestInitABAExport_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the initialization of the ABA export 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

Initialisation:
- When a payment request record is created or updated, the trigger is initialised. The PaymentRequestInitABAExport_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).
Trigger Execution:
- Upon initialisation, the trigger executes the logic defined in the PaymentRequestInitABAExport_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 ABA export is initialised to ensure each payment request has the necessary export data.
  - Update: The payment request record is updated with the newly initialised ABA export data.

Trigger Outcome:

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

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 here to view and download the complete Payment Request Schema.

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 here 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.

Error Condition Formula

AND(
    NOT(ISBLANK(maica_cc__End_Date__c)),
    maica_cc__End_Date__c < maica_cc__Start_Date__c
)

Price List Start Date Cannot Be After End Date

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

Error Condition Formula

AND(
    NOT(ISBLANK(maica_cc__Start_Date__c)),
    maica_cc__Start_Date__c > maica_cc__End_Date__c
)

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.

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 here 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.

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
)

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

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)
)
)

Weekly Hours Minimum Must Be Less Than Weekly Hours Limit

Ensures that the Weekly Hours Minimum is less than the Weekly Hours Limit.

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
)

Ensures the User lookup is populated when Resource Type = Resource.

Error Condition Formula

AND(
    ISPICKVAL(maica_cc__Resource_Type__c, "Resource"),
    ISBLANK(maica_cc__User__c)
)

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 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

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.
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.
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.
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.

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

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).
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.

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

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).
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.

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 here 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 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

Start (Record-Triggered Flow):
- The flow begins when a Resource Participant record is created or updated.
- It is triggered after the record is saved.
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.
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.

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

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

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).
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.

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.

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.

Agreement Start Date Must Be Before End Date

Ensures that the Agreement's Start Date cannot be after the End Date.

Start and End Dates Required for NDIS Funding Source

Ensures the Start and End Date are provided when the Funding Source is NDIS.

Price List Must Be Associated

Ensures that the Price List is populated.

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.

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 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

Start (Screen Flow):
- The flow is initiated.
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.
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.
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.
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.
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.
Finish Cancel Service Agreement (Screen):
- The flow displays a screen indicating the successful cancellation of the Service Agreement.
- The flow then ends.
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.
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 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

Start (Screen Flow):
- The flow is initiated.
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.
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.
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.
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.
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.
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 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

Start (Record-Triggered Flow):
- The flow begins when a service agreement is created or updated.
Get Service Agreement (Get Records):
- Retrieves the service agreement based on the provided Service Agreement Id.
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.
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.
Call Generate Service Agreement Statements Flow (Subflow):
- Calls another flow to generate service agreement statements for the specified period.
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.
Get Monthly Statements (Get Records):
- Retrieves monthly statements related to the service agreement.
Loop Through Monthly Statements (Loop):
- Iterates over the retrieved monthly statements:
  - For each statement, it adds the values to the discharge statement counters.
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
Assign Discharge Statement Values (Assignment):
- Sets the discharge statement values:
  - Issue Date
  - Period Start Date
  - Period End Date
  - Status
  - Type
Create Discharge Statement (Create Records):
- Creates the discharge statement record.
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 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

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".
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 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

Start (Auto-Triggered Flow):
- The flow is initiated, starting with the detection of changes to the Invoicing_Flow_Status__c field.
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.
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.
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.
Update Service Agreement (Update Records):
- Updates the service agreement record to set the Invoicing_Flow_Status__c field to Complete.
- Ends the flow.
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.
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 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

Start (Auto-Triggered Flow):
- The flow is initiated, starting with the retrieval of the service agreement.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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

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).
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.

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

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).
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.

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

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).
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.

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.

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 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

Start (Scheduled Flow):
- The flow runs daily at midnight.
- Filters records where Leave_Complete__c is false and Leave_Status__c is not 'Pending'.
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.
Assign Service Agreement Values (Assignment):
- Sets On_Leave__c to true.
- Increments the Consecutive_Leave_Days__c by 1.
- Sets the Service Agreement Id.
Update Service Agreement (Record Update):
- Updates the service agreement with the new values assigned.
Get Alternate Active Leave Records (Get Records):
- Retrieves any alternate active leave records related to the same service agreement.
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.
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.
Update Service Agreement (Record Update):
- Updates the service agreement with the new values assigned.
Assign Variable Values for Alternate Leave (Assignment):
- Marks Leave_Complete__c as true.
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 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

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.
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.
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.
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.
Update Service Agreement (Record Update):
- Updates the service agreement with the new values assigned.
Get Alternate Active Leave Records (Get Records):
- Retrieves any alternate active leave records related to the same service agreement.
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.
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.
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.

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

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).
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.

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

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).
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.

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.

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 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

Start (Screen Flow):
- The flow begins when a user starts the flow from the screen.
- It guides the user to initiate the recalculation process.
Recalculate Service Agreement Statement (Screen):
- Displays instructions to the user about the recalculation process.
- User clicks "Next" to proceed.
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.
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.
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.
Recalculation Complete (Screen):
- Displays a success message indicating that the Service Agreement Statement has been successfully recalculated.
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.

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.

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 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

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.
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.
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.
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.
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.
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 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

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.
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.
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.
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.
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.
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.
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.
Handle Error (Assignment):
- If an error occurs during the process, assigns the error message to the FlowFaultMessage variable.

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.

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

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.

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.

System Processes

Integrations

Settings

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 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

Agreement Start Date Must Be Before End Date

Ensures that the Agreement's Start Date cannot be after the End Date.

Validation Rule Detail

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

Price List Must Be Associated

Ensures that the Price List is populated.

Validation Rule Detail

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

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

Flow Detail

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

Start (Screen Flow):
- The flow is initiated.
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.
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.
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.
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.
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.
Finish Cancel Service Agreement (Screen):
- The flow displays a screen indicating the successful cancellation of the Service Agreement.
- The flow then ends.
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.
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 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

Start (Screen Flow):
- The flow is initiated.
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.
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.
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.
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.
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.
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 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

Start (Record-Triggered Flow):
- The flow begins when a service agreement is created or updated.
Get Service Agreement (Get Records):
- Retrieves the service agreement based on the provided Service Agreement Id.
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.
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.
Call Generate Service Agreement Statements Flow (Subflow):
- Calls another flow to generate service agreement statements for the specified period.
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.
Get Monthly Statements (Get Records):
- Retrieves monthly statements related to the service agreement.
Loop Through Monthly Statements (Loop):
- Iterates over the retrieved monthly statements:
  - For each statement, it adds the values to the discharge statement counters.
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
Assign Discharge Statement Values (Assignment):
- Sets the discharge statement values:
  - Issue Date
  - Period Start Date
  - Period End Date
  - Status
  - Type
Create Discharge Statement (Create Records):
- Creates the discharge statement record.
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

Flow Detail

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

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".
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

Flow Detail

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

Start (Auto-Triggered Flow):
- The flow is initiated, starting with the detection of changes to the Invoicing_Flow_Status__c field.
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.
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.
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.
Update Service Agreement (Update Records):
- Updates the service agreement record to set the Invoicing_Flow_Status__c field to Complete.
- Ends the flow.
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.
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

Flow Detail

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

Start (Auto-Triggered Flow):
- The flow is initiated, starting with the retrieval of the service agreement.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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

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

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).
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:

Service Agreement Name Formatting

This trigger is designed to ensure that the service agreement names are formatted correctly in Maica.

Detail

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

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).
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:

Service Agreement Validation

This trigger is designed to manage the validation of service agreements in Maica.

Detail

Execution, Logic & Outcome

Execution of Trigger Logic:

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

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).
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.