Overview

Permissions

1. Bulk Data Push Through Webhook/ERP – Allows users to push data in bulk manually.
2. Allow Data Flow to ERP – Allows users to single-push manually.
   

Core Functionalities - Application Stage Changed Trigger

How It Works

1. Manually stage is changed:
   When a user changes the application stage from the Application Manager page via single or bulk action through Web or Mobile (Android, iOS), the system identifies the change and pushes the data via the configured application stage changed trigger webhook.
   
   
2. Marketing Automation: 
   When the system automatically changes an application to another stage via any configured Marketing Automation, the system identifies the change and pushes the data via the configured application stage changed trigger webhook.
   
   
3. Workflow Rule:
   When the stage is updated as a result of workflow logic, the system identifies the change and pushes the data via the configured application stage changed trigger webhook.
   
   
4. Application Update API:
5.  When the stage is updated through the Application Update API available on our Developer Portal, the system identifies the change and pushes the data via the configured application stage changed trigger webhook.
   
   
6. Multiple Stages Configured in Same Webhook:
   If the use case is to push applications across multiple stages via the same webhook, multiple stages can be configured in the same webhook trigger.

1. Fallback Mechanism (Runs Every 30 Minutes):
   If there is any stage change case that does not get pushed in real time due to a Meritto system delay, the fallback mechanism kicks in and identifies the data that was not sent in real time. This data is then pushed using the fallback mechanism.
2. Third-Party Failure Retry (Runs Once a Day): 
   All records that fail due to third-party API errors are automatically logged by the system. These records are then identified and retried by the fallback mechanism once every day at 2:00 AM, ensuring no application update is permanently missed.

1. All scenarios are real-time first.
2. Fallback mechanisms ensure no entries are missed due to real-time and third-party failures or system delays.

Manual Push (Single/Bulk Push)

1. You can select the webhook name in the Select Logic Name dropdown through which you want to push the data.
2. The Select Trigger Point dropdown will show all the configured triggers in the selected Webhook configuration.
3. In the Select Application Stage dropdown, the user can select the stage against which the data needs to be pushed. This ensures only the matching data from the selected set is pushed.
   

Use Cases

1. Marketing Automation Sync
   If an application stage changes to Offer Letter Released, the trigger can push this data to a marketing automation platform. This enables sending automated communication (e.g., congratulations emails, onboarding instructions, or targeted ads).
   
   
2. ERP / Finance System Integration
   When an application reaches the Fee Verified stage, the trigger pushes the data update to an ERP or finance system for accounting reconciliation, ensuring no manual entry errors.
   
   
3. Third-Party Learning Management Systems (LMS)
   If the stage changes to Enrolled, the trigger can automatically create a student profile in an LMS, giving the applicant immediate access to online resources without waiting for manual processing.
   
   
4. Visa / Compliance Tracking Systems
   For international applicants, when an application moves to Document Verification Completed, the data can be pushed to a compliance or visa management system, ensuring regulatory checks are started without delay.
   
   
5. Call Center / Support System Notification
   When an application moves to Interview Scheduled, the data can be pushed to a call center tool. This ensures support teams have the latest status while handling candidate queries.

Limitations & Known Cases

When multiple stages are configured within the same webhook, if a candidate returns to a stage that has already been pushed earlier, the data will be sent only in real time. In this case, if the real-time push fails for any reason, the fallback mechanism will not re-push the entry.

Example:

If a candidate moves from Stage 1 → Stage 2 (both configured in the same webhook), data is pushed for each stage in real time. If the candidate later returns to Stage 1, the real-time push is attempted again. However, if this specific real-time push fails, the fallback process will not retry it.

Note: The unique condition of data push for this trigger now works on the Webhook ID. Therefore, if you need to push data again for an Application Stage, you should create a new webhook (which will have a different system-generated ID) instead of changing the vendor in the existing webhook.

Conclusion