This feature automates the transfer of apps to a specified Logixx status based on configurable trigger settings. It ensures leads are efficiently managed by moving inactive apps to a new status while adhering to specific criteria. The system evaluates apps in selected statuses, applying conditions such as time in status, absence of notes, and scheduled events before executing the transfer.
Trigger Settings
Applicable App Statuses: The system can monitor apps in one or more statuses (e.g., X, X1, X2, X3, X4).
Conditions:
Time in Status: The system checks how long an app has been in its current status:
App transfer to other Status : Greater than (>) or equal to (=).
Only supports hours, months or days (minutes are not supported).
No Notes: There must be no notes added within the specified number of days:
Calculation is based on the last checkpoint (the point at which the app transitioned into its current status).
The number of days must be less than the configured "day in status" threshold.
No Scheduled Events: The app must not have any open or future scheduled calendar events. This ensures that apps with upcoming actions are not moved prematurely.
Actions:
If all conditions are met:Remove All App Owners: Clear all assigned owners of the app.
Move to a New Status: Transfer the app to the specified Logixx status (e.g., Status X).
Additional Functional Requirements
Batch Processing:
To optimize performance, the system processes a maximum of 300 apps per trigger execution.
If more than 300 apps meet the trigger conditions:
The first 300 apps are processed immediately.
Remaining apps are queued for the next processing round (1 minute later)
Trigger Settings Configuration:
All parameters (statuses, time in status, note duration, and target status) can be configured by administrators.
Admins can review and adjust these settings in the Admin> Site setup > System configuration > Triggers.
The interface for managing triggers is organized into clear columns, providing easy navigation through the system’s data. As shown in the image, the columns include:
Branch: Allows users to filter triggers based on different branches or locations.
Title: Displays the title or name of each trigger, helping users quickly identify triggers by their descriptive labels.
Type: Helps classify triggers based on their type, providing another layer of sorting and filtering.
Handler Type: Displays the type of handler associated with each trigger, ensuring that users can track the corresponding actions and logic for each event.
Additionally, the interface provides powerful filters at the top, enabling users to search and sort triggers based on various criteria:
Active/Inactive Status: This filter lets users toggle between viewing active and inactive triggers.
Search & Enter: A general search bar that allows for keyword-based filtering across the triggers.
Select Branch, Trigger Types, and Handler Types: These dropdown filters give users the ability to further refine their search by selecting specific branches, types of triggers, or handler types.
These filters ensure that administrators can quickly locate specific triggers and manage them efficiently.


