Execution of Trigger Logic:

The trigger logic defined in the AgreementItemSupportItem_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the support items for agreement items.

• Trigger Conditions:

  • When a new agreement item (maica__Agreement_Item__c) is created.

  • When an existing agreement item is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Association: The support items are associated with the agreement items based on predefined criteria such as item type and service requirements.

     • Update: The agreement item record is updated with the associated support item data.

Trigger Outcome:

Once executed, the trigger ensures that each agreement item has its support items associated correctly, based on the logic defined in the handler class. This helps maintain accurate and complete data for agreement items and their support items.

Execution of Trigger Logic:

The trigger logic defined in the AgreementItemEstExpenditure_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the estimated expenditure process for agreement items.

• Trigger Conditions:

  • When a new agreement item (maica__Agreement_Item__c) is created.

  • When an existing agreement item is updated.

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

Logic Explanation

1. Initialisation:

   • When an agreement item record is created or updated, the trigger is initialised. The AgreementItemEstExpenditure_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Calculation: The estimated expenditure is calculated based on predefined criteria such as item type and service duration.

     • Update: The agreement item record is updated with the newly calculated estimated expenditure data.

Trigger Outcome:

Once executed, the trigger ensures that each agreement item has its estimated expenditure calculated correctly, based on the logic defined in the handler class. This helps maintain accurate financial data for agreement items.

Execution of Trigger Logic:

The trigger logic defined in the AgreementItemRollupExpenditure_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the rollup expenditure process for agreement items.

• Trigger Conditions:

  • When a new agreement item (maica__Agreement_Item__c) is created.

  • When an existing agreement item is updated.

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

Logic Explanation

1. Initialisation:

   • When an agreement item record is created or updated, the trigger is initialised. The AgreementItemRollupExpenditure_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Calculation: The total expenditure is calculated based on predefined criteria such as item type and financial rules.

     • Update: The agreement item record is updated with the newly calculated rolled-up expenditure data.

Trigger Outcome:

Once executed, the trigger ensures that each agreement item has its expenditures rolled up correctly, based on the logic defined in the handler class. This helps maintain accurate financial data for agreement items.

Execution of Trigger Logic:

The trigger logic defined in the AgreementItemTotalAllocated_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the total allocation process for agreement items.

• Trigger Conditions:

  • When a new agreement item (maica__Agreement_Item__c) is created.

  • When an existing agreement item is updated.

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

Logic Explanation

1. Initialisation:

   • When an agreement item record is created or updated, the trigger is initialised. The AgreementItemTotalAllocated_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 3.0).

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Calculation: The total allocated amount is calculated based on predefined criteria such as item type and allocation rules.

     • Update: The agreement item record is updated with the newly calculated total allocated data.

Trigger Outcome:

Once executed, the trigger ensures that each agreement item has its total allocated amount calculated correctly, based on the logic defined in the handler class. This helps maintain accurate financial data for agreement items.

1. Start (Record-Triggered Flow):

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

2. Calculate Is Active Status (Formula):

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

3. Update Funding Item Record (Record Update):

   • Updates the Is Active field with the calculated status.

1. Start (Record-Triggered Flow):

   • Triggered before inserting or updating a Funding Item record.

2. Calculate Unit of Measurement (Formula):

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

3. Assign Plan Budget Values (Assignment):

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

1. Start (Record-Triggered Flow):

   • The flow is triggered upon the update of a funding record.

   • The flow runs asynchronously after the record is saved.

   • Proceeds to a fake assignment to fix a packaging issue.

2. Fake Assignment (Assignment):

   • This step exists to ensure the flow runs properly due to a packaging issue.

   • Proceeds to the decision step to check if the email template in the email setting is null.

3. Is Template in Email Setting Null? (Decision):

   • Checks if the templateFromEmailSetting is null.

   • No: If the template is not null, proceeds to the decision step to determine the email recipient.

   • Yes: Ends the flow.

4. To whom should this message be delivered? (Decision):

   • Checks the recipient from the email setting and determines who should receive the email.

   • Recipient In Email Setting Equals Current Participant Owner: Assigns the participant owner's ID to UserIdToSendEmail and proceeds to send the email.

   • Recipient In Email Setting Equals User And User Id In Email Setting Is Not Null: Assigns the user ID from the email setting to UserIdToSendEmail and proceeds to send the email.

5. Set Plan Participant Owner Id (Assignment):

   • Assigns the participant owner's ID to UserIdToSendEmail.

   • Proceeds to send the email.

6. Set User Id (Assignment):

   • Assigns the user ID from the email setting to UserIdToSendEmail.

   • Proceeds to send the email.

7. Send Email (Apex Action):

   • Calls the SendEmailInvocable Apex action to send the email.

   • Passes the email template, from email address, and recipient ID as input parameters.

   • Ends the flow.

Execution of Trigger Logic:

The trigger logic defined in the FundingAdjustRecurringInvoices_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the adjustment process for recurring invoices.

• Trigger Conditions:

  • When a new funding record (maica_cc__Funding__c) is created.

  • When an existing funding record is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

     • Validation: The funding record data is validated to ensure it is complete and accurate.

     • Adjustment: Recurring invoices are adjusted based on changes to the funding record details, such as modifications to the services or billing frequency.

     • Update: The funding record is updated with the newly adjusted invoice data.

Trigger Outcome:

Once executed, the trigger ensures that recurring invoices for funding records are adjusted correctly, according to the logic specified in the handler class. This helps maintain accurate invoice data for funding records.

Execution of Trigger Logic:

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

• Trigger Conditions:

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

  • When an existing delivery activity is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

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

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

Trigger Outcome:

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

Execution of Trigger Logic:

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

• Trigger Conditions:

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

  • When an existing delivery activity is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

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

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

Trigger Outcome:

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

1. Start (Record-Triggered Flow):

   • The flow is initiated upon the creation or update of a participant record.

   • Checks if the latitude and longitude are set to 0.0 and ensures that the address fields (MailingCity, MailingPostalCode, MailingStreet, and MailingState) are not null.

   • Proceeds to geocode the address asynchronously after the record is saved.

2. Geocode the Address (Apex Action):

   • Calls the GeocodeAddressInvocableProc Apex action to geocode the address.

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

   • Captures the latitude and longitude from the geocoding result.

   • Proceeds to the Error decision.

3. Error? (Decision):

   • Checks if there is an error message from the geocoding process.

   • If no error, proceeds to update the participant record with the geocoded latitude and longitude.

   • If an error is detected, the flow ends.

4. Update Participant (Update Records):

   • Updates the participant record with the latitude and longitude from the geocoding result.

   • Ends the flow.

Execution of Trigger Logic:

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

• Trigger Conditions:

  • When a new participant (Contact) is created.

  • When an existing participant is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

     • Validation: The participant's address data is validated to ensure it is complete and accurate.

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

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

Trigger Outcome:

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

Execution of Trigger Logic:

The trigger logic defined in the ContactUpdateConnectionsType_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the updating process for connection types.

• Trigger Conditions:

  • When a new contact (Contact) is created.

  • When an existing contact is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Update: The connection type is updated based on predefined criteria such as contact status or type.

     • Notification: Relevant stakeholders are notified if necessary, ensuring that all parties are aware of the updates.

Trigger Outcome:

Once executed, the trigger ensures that each contact's connection type is updated correctly, based on the logic defined in the handler class. This helps maintain accurate data and operational efficiency.

1. Start (Record-Triggered Flow):

   • The flow is triggered upon the creation or update of an appointment record.

   • The flow runs asynchronously after the record is saved.

   • Proceeds to geocode the address.

2. Geocode the Address (Apex Action):

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

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

   • Proceeds to the decision step to check for errors.

3. Error? (Decision):

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

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

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

4. Update Appointment (Record Update):

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

   • Ends the flow.

Execution of Trigger Logic:

The trigger logic defined in the AppointmentTimeSheet_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the timesheet process for appointments.

• Trigger Conditions:

  • When a new appointment (maica__Appointment__c) is created.

  • When an existing appointment is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Timesheet Creation/Update: Based on the appointment details, timesheet entries are created or updated to reflect the time spent on the appointment.

     • Update: The appointment record is updated with the newly created or updated timesheet data.

Trigger Outcome:

Once executed, the trigger ensures that each appointment has its timesheet entries created or updated correctly, based on the logic defined in the handler class. This helps maintain accurate timesheet data for appointments.

Execution of Trigger Logic:

The trigger logic defined in the AppointmentStatus_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the status updates for appointments.

• Trigger Conditions:

  • When a new appointment (maica__Appointment__c) is created.

  • When an existing appointment is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Status Update: The appointment status is updated based on predefined criteria such as appointment type, time, and other relevant factors.

     • Notification: Relevant stakeholders are notified if necessary, ensuring that all parties are aware of the status changes.

Trigger Outcome:

Once executed, the trigger ensures that each appointment has its status updated correctly, based on the logic defined in the handler class. This helps maintain accurate status tracking for appointments.

Execution of Trigger Logic:

The trigger logic defined in the AppointmentRollupParticipants_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the rollup of participants for appointments.

• Trigger Conditions:

  • When a new appointment (maica__Appointment__c) is created.

  • When an existing appointment is updated.

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

Logic Explanation

1. Initialisation:

   • When an appointment record is created or updated, the trigger is initialised. The AppointmentRollupParticipants_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 3.0).

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Calculation: The total number of participants is calculated based on predefined criteria such as appointment type and participant status.

     • Update: The appointment record is updated with the newly calculated rolled-up participant data.

Trigger Outcome:

Once executed, the trigger ensures that each appointment has its participants rolled up correctly, according to the logic specified in the handler class. This helps maintain accurate participant data for appointments.

Execution of Trigger Logic:

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

• Trigger Conditions:

  • When a new appointment (maica__Appointment__c) is created.

  • When an existing appointment is updated.

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

Logic Explanation

1. Initialisation:

   • When an appointment record is created or updated, the trigger is initialised. The AppointmentGeocode_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 4.0).

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

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

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

Trigger Outcome:

Once executed, the trigger ensures that each appointment is geocoded correctly, according to the logic specified in the handler class. This helps maintain accurate geographical data for appointments.

Execution of Trigger Logic:

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

• Trigger Conditions:

  • When a new appointment (maica__Appointment__c) is created.

  • When an existing appointment is updated.

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

Logic Explanation

1. Initialisation:

   • When an appointment record is created or updated, the trigger is initialised. The AppointmentDeliveryActivities_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 6.0).

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Activity Creation/Update: Based on the appointment details, delivery activities are created or updated to reflect the services or tasks associated with the appointment.

     • Update: The appointment record is updated with the newly created or updated delivery activity data.

Trigger Outcome:

Once executed, the trigger ensures that each appointment has its delivery activities created or updated correctly, according to the logic specified in the handler class. This helps maintain accurate delivery activity data for appointments.

1. Start (Record-Triggered Flow):

   • The flow begins when an invoice line item is created or updated.

   • It is triggered before the record is saved.

2. Set Line Total and GST (Assignment):

   • Calculates and assigns the line total, GST amount, and amount for the invoice line item.

3. Evaluate Status (Decision):

   • The flow checks the status of the invoice line item based on various conditions:

     • Claim Type = Home Care Package: Proceeds to evaluate further conditions.

     • Entered: If the line total is greater than 0, the claim count is 0, the claim balance equals the line total, and the paid amount is 0, it sets the status to "Entered".

     • Claimed: If the line total is greater than 0, the claim count is greater than 0, the claim balance equals the line total, and the paid amount is 0, it sets the status to "Claimed".

     • Fully Paid: If the line total is greater than 0, the claim count is greater than 0, the claim balance is less than or equal to 0, and the paid amount is greater than or equal to the line total, it sets the status to "Fully Paid".

     • Partially Paid: If the line total is greater than 0, the claim count is greater than 0, the claim balance is greater than 0 but less than the line total, and the paid amount is less than the line total, it sets the status to "Partially Paid".

     • Not Paid: If the line total is greater than 0, the claim count is greater than 0, the claim balance is greater than 0, and the paid amount is 0, it sets the status to "Not Paid".

4. Set Entered Status (Assignment):

   • Sets the invoice line item status to "Entered".

5. Set Claimed Status (Assignment):

   • Sets the invoice line item status to "Claimed".

6. Set Fully Paid Status (Assignment):

   • Sets the invoice line item status to "Fully Paid".

7. Set Partially Paid Status (Assignment):

   • Sets the invoice line item status to "Partially Paid".

8. Set Not Paid Status (Assignment):

   • Sets the invoice line item status to "Not Paid".

Execution of Trigger Logic:

The trigger logic defined in the InvoiceLineRollupExpenditure_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the rollup expenditure process for invoice line items.

• Trigger Conditions:

  • When a new invoice line item (maica__Invoice_Line_Item__c) is created.

  • When an existing invoice line item is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

     • Validation: The expenditure data for each line item is validated to ensure it is complete and accurate.

     • Calculation: The total expenditure is calculated based on the line items of the invoice, taking into account the item types and financial rules.

     • Update: The invoice record is updated with the newly calculated rolled-up expenditure data.

Trigger Outcome:

Once executed, the trigger ensures that each invoice line item has its expenditures rolled up correctly, according to the logic specified in the handler class. This helps maintain accurate financial data for invoices.

Execution of Trigger Logic:

The trigger logic defined in the InvoiceLineBookingItem_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the booking items process for invoice line items.

• Trigger Conditions:

  • When a new invoice line item (maica__Invoice_Line_Item__c) is created.

  • When an existing invoice line item is updated.

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

Logic Explanation

1. Initialisation:

   • When an invoice line item record is created or updated, the trigger is initialised. The InvoiceLineBookingItem_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 2.0).

2. Trigger Execution:

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

   • The class methods perform the following steps:

     • Validation: The booking item data for each line item is validated to ensure it is complete and accurate.

     • Linking: Booking items are linked to the corresponding invoice line items, ensuring that the relationship between booking items and invoice line items is correctly established.

     • Update: The invoice line item record is updated with the newly linked booking item data.

Trigger Outcome:

Once executed, the trigger ensures that each invoice line item has its booking items linked correctly, according to the logic specified in the handler class. This helps maintain accurate booking item data for invoice line items.

1. Start (Record-Triggered Flow):

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

   • The flow runs asynchronously after the record is saved.

   • Proceeds to geocode the address.

2. Geocode the Address (Apex Action):

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

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

   • Proceeds to the decision step to check for errors.

3. Error? (Decision):

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

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

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

4. Update Location (Record Update):

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

   • Ends the flow.

Execution of Trigger Logic:

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

• Trigger Conditions:

  • When a new location (maica__Location__c) is created.

  • When an existing location is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

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

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

Trigger Outcome:

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

Execution of Trigger Logic:

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

• Trigger Conditions:

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

  • When an existing payment request is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

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

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

Trigger Outcome:

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

1. Start (Record-Triggered Flow):

   • Object: Invoice__c

   • Trigger: When the invoice record is updated or created.

   • Input Variable: recordId

2. Get Invoice (Record Lookup):

   • Filters: Retrieves the invoice record where the Id matches recordId.

   • Connector: Proceeds to check the invoice status.

3. Invoice Status (Decision):

   • Conditions: Checks if the invoice status is "Cancelled".

   • If "Cancelled": Displays the "Invoice Cancelled" screen.

   • If not "Cancelled": Proceeds to the "Cancel Invoice" screen.

4. Cancel Invoice (Screen):

   • Displays a confirmation message asking the user to confirm the cancellation of the invoice.

   • Connector: Proceeds to set the invoice as cancelled upon confirmation.

5. Set Invoice Cancelled (Assignment):

   • Sets the Cancelled__c field of the invoice to true.

   • Connector: Proceeds to update the invoice.

6. Update Invoice (Record Update):

   • Updates the invoice record with the cancelled status.

   • Connector: Proceeds to display the "Invoice Cancelled" screen.

7. Invoice Cancelled (Screen):

   • Displays a message confirming that the invoice has been cancelled.

1. Start (Record-Triggered Flow):

   • The flow begins when an invoice is created or updated.

   • It is triggered before the record is saved.

2. Status Evaluation (Decision):

   • The flow checks the status of the invoice based on various conditions:

     • If the invoice is cancelled, it proceeds to set the status to "Cancelled".

     • If all line items are not paid, it proceeds to set the status to "Not Paid".

     • If the invoice is partially paid and managed by an agency, it checks further conditions and then sets the status to "Partially Paid".

     • If the invoice is fully paid and managed by an agency, it checks further conditions and then sets the status to "Fully Paid".

     • For non-agency managed invoices, it similarly checks and sets the status to "Partially Paid" or "Fully Paid" based on payment details.

3. Set Cancelled (Assignment):

   • Sets the invoice status to "Cancelled".

4. Set Not Paid Status (Assignment):

   • Sets the invoice status to "Not Paid".

5. Set Partially Paid Status (Assignment):

   • Sets the invoice status to "Partially Paid".

6. Set Fully Paid Status (Assignment):

   • Sets the invoice status to "Fully Paid".

Execution of Trigger Logic:

The trigger logic defined in the InvoiceManageClaimSchedule_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the claim schedule process for invoices.

• Trigger Conditions:

  • When a new invoice (maica__Invoice__c) is created.

  • When an existing invoice is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Claim Scheduling: Based on the invoice details, claims are scheduled to reflect the payment plan and due dates.

     • Update: The invoice record is updated with the newly scheduled claim data.

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its claim schedule managed correctly, according to the logic specified in the handler class. This helps maintain accurate claim schedule data for invoices.

Execution of Trigger Logic:

The trigger logic defined in the InvoiceNextScheduledDate_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the next scheduled date process for invoices.

• Trigger Conditions:

  • When a new invoice (maica__Invoice__c) is created.

  • When an existing invoice is updated.

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

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Date Calculation: Based on the invoice details, the next scheduled date is calculated to reflect the payment plan and due dates.

     • Update: The invoice record is updated with the newly calculated next scheduled date.

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its next scheduled date calculated correctly, according to the logic specified in the handler class. This helps maintain accurate scheduling data for invoices.

Execution of Trigger Logic:

The trigger logic defined in the InvoiceDefaults_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the setting of default values for invoices.

• Trigger Conditions:

  • When a new invoice (maica__Invoice__c) is created.

  • When an existing invoice is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Default Setting: Based on predefined criteria, default values such as payment terms, due dates, and invoice status are set.

     • Update: The invoice record is updated with the newly set default values.

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its default values set correctly, according to the logic specified in the handler class. This helps maintain accurate and consistent data for invoices.

Execution of Trigger Logic:

The trigger logic defined in the InvoiceRollupExpenditure_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the rollup expenditure process for invoices.

• Trigger Conditions:

  • When a new invoice (maica__Invoice__c) is created.

  • When an existing invoice is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Calculation: The total expenditure is calculated based on predefined criteria such as item type and financial rules.

     • Update: The invoice record is updated with the newly calculated rolled-up expenditure data.

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its expenditures rolled up correctly, according to the logic specified in the handler class. This helps maintain accurate financial data for invoices.

Execution of Trigger Logic:

The trigger logic defined in the InvoiceClaim_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the claim process for invoices.

• Trigger Conditions:

  • When a new invoice (maica__Invoice__c) is created.

  • When an existing invoice is updated.

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

Logic Explanation

1. Initialisation:

   • When an invoice record is created or updated, the trigger is initialised. The InvoiceClaim_MDTM metadata type configuration is loaded, ensuring that the trigger is active (Active__c is true) and has the correct load order (Load_Order__c is 10.0).

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

     • Claim Generation: Based on the invoice details, claims are generated to reflect the amounts and payment plans specified.

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

Trigger Outcome:

Once executed, the trigger ensures that each invoice has its claims processed correctly, according to the logic specified in the handler class. This helps maintain accurate claim data for invoices.

1. Start (Scheduled Flow):

   • The flow runs daily at midnight.

   • Filters records where Leave_Complete__c is false and Leave_Status__c is not 'Pending'.

2. Decision Leave Status (Decision):

   • Determines the leave status:

     • If Leave Status is 'Active', it assigns service agreement values and updates the service agreement.

     • If Leave Status is 'Complete', it checks for alternate active leave records.

3. Assign Service Agreement Values (Assignment):

   • Sets On_Leave__c to true.

   • Increments the Consecutive_Leave_Days__c by 1.

   • Sets the Service Agreement Id.

4. Update Service Agreement (Record Update):

   • Updates the service agreement with the new values assigned.

5. Get Alternate Active Leave Records (Get Records):

   • Retrieves any alternate active leave records related to the same service agreement.

6. Decision Alternate Active Leave (Decision):

   • Determines if there are alternate active leave records:

     • If there are, it assigns variable values for the leave status and updates the service agreement leave.

     • If there are not, it assigns variable values to mark the leave as complete and updates the service agreement.

7. Assign Variable Values (Assignment):

   • Sets On_Leave__c to false.

   • Marks Leave_Complete__c as true.

   • Resets Consecutive_Leave_Days__c to 0.

   • Sets the Service Agreement Id.

8. Update Service Agreement (Record Update):

   • Updates the service agreement with the new values assigned.

9. Assign Variable Values for Alternate Leave (Assignment):

   • Marks Leave_Complete__c as true.

10. Update Service Agreement Leave (Record Update):

    • Updates the service agreement leave record.

1. Start (Record-Triggered Flow):

   • The flow begins when a Service Agreement Leave record is created or updated.

   • It is triggered after the record is saved.

   • The flow is triggered by changes to Start Date, End Date, or when the record is newly created.

2. Decision Leave Status (Decision):

   • Determines the leave status:

     • If Leave Status is 'Active', it checks the Leave Start Date.

     • If Leave Status is 'Complete', it checks for alternate active leave records.

3. Decision Leave Start Date (Decision):

   • Checks if the Leave Start Date is equal to the current date:

     • If yes, it assigns service agreement values and updates the service agreement.

     • If the Leave Start Date is before the current date, it assigns service agreement values using a calculation and updates the service agreement.

4. Assign Service Agreement Values (Assignment):

   • Sets On_Leave__c to true.

   • Increments the Consecutive_Leave_Days__c by 1 or calculates it based on the current date.

   • Sets the Service Agreement Id.

5. Update Service Agreement (Record Update):

   • Updates the service agreement with the new values assigned.

6. Get Alternate Active Leave Records (Get Records):

   • Retrieves any alternate active leave records related to the same service agreement.

7. Decision Alternate Active Leave (Decision):

   • Determines if there are alternate active leave records:

     • If there are, it assigns variable values for the leave status and updates the service agreement leave.

     • If there are not, it assigns variable values to mark the leave as complete and updates the service agreement.

8. Assign Variable Values (Assignment):

   • Sets On_Leave__c to false.

   • Marks Leave_Complete__c as true.

   • Resets Consecutive_Leave_Days__c to 0.

   • Sets the Service Agreement Id.

9. Update Service Agreement Leave (Record Update):

   • Updates the service agreement leave record.

Execution of Trigger Logic:

The trigger logic defined in the ServiceAgreementLeaveOverlap_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the overlap check process for service agreement leave periods.

• Trigger Conditions:

  • When a new service agreement leave (maica__Service_Agreement_Leave__c) is created.

  • When an existing service agreement leave is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

     • Validation: The leave period data is validated to ensure it is complete and accurate.

     • Overlap Check: Existing leave periods in the service agreement are checked for overlaps with the new or updated leave period.

     • Update: If an overlap is detected, the service agreement leave record is updated with overlap information to indicate the conflict.

Trigger Outcome:

Once executed, the trigger ensures that each service agreement leave period is checked for overlaps correctly, according to the logic specified in the handler class. This helps maintain accurate leave period data and prevents conflicts in service agreements.

Execution of Trigger Logic:

The trigger logic defined in the ServiceAgreementLeaveAppointments_MDTM class is executed when the trigger conditions are met. The class contains the code that manages the appointment management process for service agreement leave periods.

• Trigger Conditions:

  • When a new service agreement leave (maica__Service_Agreement_Leave__c) is created.

  • When an existing service agreement leave is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

     • Validation: The leave period data is validated to ensure it is complete and accurate.

     • Appointment Management: Based on the leave period, related appointments are either created or updated to ensure they reflect the leave period accurately.

     • Update: The service agreement leave record is updated with the newly managed appointment data if necessary.

Trigger Outcome:

Once executed, the trigger ensures that each service agreement leave period has its related appointments managed correctly, according to the logic specified in the handler class. This helps maintain accurate appointment data and ensures that all appointments are in sync with leave periods.

1. Start (Record-Triggered Flow):

   • The flow is initiated upon the creation or update of a resource record.

   • Checks if the latitude and longitude are set to 0.0 and ensures that the address fields (City, Street, State, and Postal Code) are not null.

   • Proceeds to geocode the address asynchronously after the record is saved.

2. Geocode the Address (Apex Action):

   • Calls the GeocodeAddressInvocableProc Apex action to geocode the address.

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

   • Captures the latitude and longitude from the geocoding result.

   • Proceeds to the Error decision.

3. Error? (Decision):

   • Checks if there is an error message from the geocoding process.

   • If no error, proceeds to update the resource record with the geocoded latitude and longitude.

   • If an error is detected, the flow ends.

4. Update Resource (Update Records):

   • Updates the resource record with the latitude and longitude from the geocoding result.

   • Ends the flow.

Trigger Execution

The trigger logic defined in the ResourceDeactivation_MDTM class is executed when the trigger conditions are met.

• Trigger Conditions:

  • When a new resource (maica__Resource__c) is created.

  • When an existing resource is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

     • Validation: The resource status and related data are validated to ensure they meet the criteria required for deactivation.

     • Deactivation: The deactivation process is applied based on predefined criteria such as resource status and utilisation.

     • Update: Related records are updated, and relevant stakeholders are notified if necessary.

Trigger Outcome:

Once executed, the trigger ensures that each resource is deactivated correctly, based on the logic defined in the handler class. This helps maintain data integrity and operational efficiency.

Trigger Execution

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

• Trigger Conditions:

  • When a new resource (maica__Resource__c) is created.

  • When an existing resource is updated.

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

Logic Explanation

1. Initialisation:

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

2. Trigger Execution:

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

   • The class methods perform the following steps:

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

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

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

Trigger Outcome:

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