Modeling Clarity's Apps
Here, you'll apply the data modeling principles and best practices you've learned to begin planning Clarity's app. This involves identifying their necessary data entities, attributes, and relationships. By carefully modeling these elements, you can create a robust and efficient solution that effectively supports Clarity's needs.
Clarity’s Distributor Management App
To effectively manage distributor onboarding, Clarity requires an app that captures and organizes key information about prospective distributors as well as internal evaluations of applicants. This involves modeling two primary data entities:
-
Distributor Applications: Stores applications submitted by prospective distributors.
-
Application Evaluations: Stores internal evaluations of applicants.
This separation of entities aligns with the denormalized approach to data modeling, where each object represents a complete, self-contained unit of information. This strategy minimizes the need for complex joins and optimizes data retrieval, especially when leveraging Liferay's page builder features or headless APIs to display or access entries.
The Distributor Applications object should store the necessary business information for verifying each applicant's identity and credit for Know Your Customer (KYC) best practices and compliance with Anti-Money Laundering (AML) laws. Additionally, Clarity wants to collect information for assessing the relative value of each prospective distributor. They also want to track the state of each application throughout the review process, independent of the entry’s workflow status.
The Application Evaluations object should store all necessary data generated during the review process. This includes qualitative and quantitative assessments, recommendations, supporting documents, and the final decision.
In Clarity’s distributor management app, a single application can relate to multiple evaluations, while each evaluation should only ever relate to one application. This means the Distributor Applications and Application Evaluations entities should have a one-to-many relationship.
Clarity’s Ticketing App
Clarity's support team requires a robust ticketing system to efficiently manage support requests from both customers and business partners. This app should track all relevant ticket information and facilitate seamless communication and resolution processes.
For this app, a single data entity (Tickets) is sufficient to capture all necessary information. This entity can serve as a comprehensive model for all ticket-related data, including the ticket’s type, description, priority, region, and status.
To effectively track ticket assignments and manage complex support issues, the Tickets entity requires two key relationships. First, a relationship with Liferay's default Users entity enables Clarity to assign tickets to specific employees within their system, improving their workflow. Second, Clarity wants to relate tickets in a hierarchical relationship and enable parent-child ticket associations. This enables support to break down complex issues into smaller, more manageable sub-tickets, promoting efficient tracking and resolution.
This structure, with a single comprehensive Ticket entity and its associated relationships, aligns with the denormalization principle. It ensures that all relevant ticket information is readily accessible and minimizes the number of calls required, promoting efficient data retrieval and improving performance.
Conclusion
Having a well-defined plan for your data model is crucial for successful Liferay Object implementations. Next, you’ll learn how to start implementing Clarity’s apps with objects.
Capabilities
Product
Education
Contact Us