Welcome to the “📇 Building a CRM from Scratch” tutorial! 🎉 (Part 1)
Here, we’ll guide you step-by-step through using our low-code platform to easily create a simple CRM system. Whether you’re a programming novice or an experienced developer, you’ll find joy and a sense of achievement in this process.
CRM, short for Customer Relationship Management, is typically referred to as CRM system software. CRM is a customer-centric software system specifically designed for managing customer relationships. It ensures that every interaction with customers in sales, marketing, and service is smooth and efficient, thereby improving business performance.
Are you ready? Let’s get started and take the first step towards success! 🚀
How to Model Customer Objects on a Low-Code Platform
Business model design is the foundation of information system design, involving the definition of database tables, field settings, and relationships between tables. In short, this step determines the data structure and storage method of the system.
Customers are one of the core objects managed by CRM systems. We will first create a customer object with the following attributes:
Customer Model Definition in CRM System
Model Name
Model Description | Description |
---|---|
Customers | Customer information, including name, contact information, company name, position, etc. |
Model Field List
Field Name | Type | Nullable | Default Value | Options | Remarks |
---|---|---|---|---|---|
name | STRING | No | None | None | Customer business key |
contactInfo | STRING | No | None | None | Contact information |
companyName | STRING | Yes | None | None | Company name |
position | STRING | Yes | None | None | Position |
group | STRING | Yes | None | None | Customer group |
birthday | LOCAL_DATE | Yes | None | None | Customer birthday |
The system will automatically create an auto-increment column named
id
of type Long as the primary key.
Creating Models in the Low-Code Platform
Creating Customer Model and Fields
The operation video is shown below
Setting Enumeration Values for the Group Field
The group field is used to identify customer group ings. We can set its enumeration values as follows:
Model Name | Enumeration Field | Option Value | Explanation |
---|---|---|---|
Customer Form (Customers) | Group (Customer Group) | VIP | Very important customers |
Regular Customer | General customers | ||
Potential Customer | Potential customers who may become actual customers | ||
Important Customer | Customers who are very important in business | ||
Blacklist | Customers no longer cooperating with |
In the field definition, you can set optional values for the field. The specific operation is to edit the field and set its options property, as shown in the video below:
Next, we will create corresponding CRUD forms for the created customer model.
Creating Maintenance Forms for the Customer Model
Forms are an important component in the system. All data management is performed on corresponding forms. We will create the following maintenance forms for the customer model:
- List form, and associate it with an access menu
- Create form
- Edit form
- Query form
Creating the List Form
The specific operation video is as follows:
In the above video, we:
- Created a list form named “List of Customers” for the customer model to display the customer list in the customer management menu.
- When creating this list form, we also created an associated menu as the entry point for users to access Customer data.
- And in the form, we assigned the corresponding view permission to the ROLE_USER role.
Creating Other Forms
The specific operation video is as follows:
In the above video, we:
- Created forms named “Create Customer” and “Update Customer”.
- Assigned the corresponding create and edit permissions to the ROLE_USER role.
- Demonstrated creating and editing Customer data in the interface.
As you can see, after creating the Create Customer and Update Customer forms, we didn’t add any fields to the forms. The system’s default behavior is: if no form fields are defined in a form, it will display all fields of that object by default.
Next, we will model the sales opportunity object and demonstrate how to establish object associations during modeling.
Sales Opportunity Object Modeling and Forms
In the previous steps, we have defined the customer object and its attributes, and defined its list, creation, and update forms. Now we will proceed with the modeling and form definition for sales opportunities.
Referring to CRM System Design, we will define the attributes of sales opportunities as follows:
Sales Opportunity Table (SalesOpportunities)
Model Definition
Interaction Record Table (InteractionRecord)
Field Name | Type | Nullable | Default | Options | Remarks | Related Object Type |
---|---|---|---|---|---|---|
name | STRING | No | None | None | Interaction record key | None |
interactionType | STRING | No | None | None | Interaction type | None |
interactionDate | LOCAL_DATE | No | None | None | Interaction date | None |
notes | STRING | Yes | None | None | Notes | None |
Task Table (Task)
Field Name | Type | Nullable | Default | Options | Remarks | Related Object Type |
---|---|---|---|---|---|---|
name | STRING | No | None | None | Task key | None |
description | STRING | No | None | None | Description | None |
dueDate | LOCAL_DATE | No | None | None | Due date | None |
status | STRING | No | None | None | Task status | None |
Sales Opportunity Table (SalesOpportunities)
Field Name | Type | Nullable | Default | Options | Remarks | Related Object Type |
---|---|---|---|---|---|---|
name | STRING | No | None | None | Sales opportunity key | None |
customer | DOMAIN_OBJECT | No | None | None | Related customer | Customers |
stage | STRING | No | None | None | Opportunity stage | None |
expectedAmount | BIG_DECIMAL | No | None | None | Expected amount | None |
expectedCloseDate | LOCAL_DATE | No | None | None | Expected closing date | None |
interactionRecords | DOMAIN_OBJECT_LIST | Yes | None | None | Customer interaction records | InteractionRecord |
tasks | DOMAIN_OBJECT_LIST | Yes | None | None | Customer interaction records | Task |
Here’s the creation process and related explanations:
- The customer field will be associated with the customer object we defined earlier. When creating this field, you need to select the type as
DOMAIN_OBJECT
and set its reference object type to Customers. - We have set options for the interactionType field of InteractionRecord, the status field of Task, and the stage field of SalesOpportunities. You can directly input options in the Options column, pressing enter to input each option.
- SalesOpportunities references the interaction record table and task table, used to record a specific interaction with the customer or a to-do task. This type of object relationship is configured using
DOMAIN_OBJECT_LIST
.
Form Definition
After completing the model definition, we will continue to define its list, creation, and update forms. The steps are as follows:
Optimizing Customer Related Object Display
From the video, we can see that the Customer field in the sales opportunity list displays its ID rather than its name, which is not user-friendly. Now we will use the extInfo feature of DomainClass to set the Customer object to display its name
attribute in other object forms that reference it.
The specific steps are as follows:
In the extension information field of the DomainClass definition for the Customer model, set:
Copied!{ "labelField": "name" }
This specifies that the name
attribute of the Customer object will be displayed in forms of other objects that reference it.
Using Sub-tables for Related Data Maintenance
The following data has a one-to-many relationship with SalesOpportunities, and the platform supports displaying related objects in sub-table form by default.
- Interaction Records Table (InteractionRecords)
- Tasks Table (Tasks)
However, when you click the create button on the SalesOpportunities list page and open the creation form, you’ll find that you can’t create related InteractionRecord and Task objects. The specific interface is shown in the image below:
This is because we haven’t granted the user permission to create and edit InteractionRecord and Task objects.
Let’s fix this permission issue. The solution is to create Create and Update forms for the InteractionRecord and Task models, and set their Enable Roles to the list of roles that should have permission.
![](https://i0.wp.com/lcdp.ai/wp-content/uploads/2024/06/image.png?resize=1024%2C386&ssl=1)
The specific operation is shown in the video below, which also demonstrates data maintenance of the SalesOpportunity object after granting user permissions:
Object Deletion Permissions
Granting Users Object Deletion Permissions
To give users the ability to delete Customers
and SalesOpportunities
objects, we need to grant them permission to delete the corresponding APIs.
This operation is performed in:
![](https://i0.wp.com/localhost/step_by_step_tutorial/requestmap_operation_path.png)
The specific steps are shown below:
Executing Batch Delete Actions
The system has built-in batch delete action definitions that can be bound to objects and implement batch delete operations. The specific steps are as follows:
During the operation, creating a DynamicActionDomainClass
object essentially binds a dynamic action to a specific model. Dynamic actions are one of the core concepts of the LCDP.ai low-code platform. For more information about dynamic actions, please refer to the dynamic action documentation in the appendix.
Additionally, the system supports using DynamicLogic
to dynamically calculate at runtime whether an object can be deleted. For details, please refer to the dynamic permission control section in the appendix.
The prerequisite for the batch delete Action to work properly is that the current logged-in user has been granted object deletion permissions as per the operations in the previous section.
In the next step, we will customize the display and input controls for certain fields.
Form Field Display Optimization
In the previous modeling and form creation process, all form fields used default rendering controls. For example, character types used character input boxes, and numeric types used numeric input boxes.
In this section, we will customize the display controls for some fields. Below is a list of fields that need to be modified:
Model | Field | Form | Display Control |
---|---|---|---|
Customer | contactInfo | Create, Update/View | Long Text |
SalesOpportunities | Expected Amount | Create, Update/View | Currency |
The display control for form fields is customized using the displayType
property in DynamicFormField
. For specific operation steps, please refer to the video below:
In the previous chapters, we only created the corresponding forms without adding form field definitions. In this case, the system will display all fields in the model by default. If you want to customize the display and input controls for fields, you need to create form fields.
Please refer to the list below for the default supported displayType
list:
Display Type |
---|
Id |
String |
Integer |
Decimal |
Currency |
Percentage |
Datetime |
Date |
Object |
Array |
Array with details |
Array Inline |
Multiple select |
Object multiple select |
Tags |
Tag list |
Code |
Static field |
Http method |
Roles |
Password |
Updated ids |
Series |
Line chart |
Tree select |
Cron expression |
Stacktrace |
JSON |
Markdown |
Object ids |
Text(long string) |
Single file |
Single image |
Document |
Grouped grand child |
Url |
Icon |
Zoned Datetime |
Sub table |
Entity Attributes |
Value select |
Function Editor |
Comments |
Further discussion
Online Community
Please join our low code development community on community.lcdp.ai to discuss more about dynamic actions and other low code development topics.
Tweet
You can find us on Twitter at LCDP.ai to share your thoughts on dynamic actions and other low code development topics.
Leave a Reply