APITable: A low code solution for Simple CRM with advanced ACL

APITable is the new kid on the block when come to low code / no code industry. It was founded in 2022. As low code platform, APITable been provide impressive functionalities in my opinion.

For a simple CRM database, APITable definitely offered more than enough features, and surprisingly, the ACL provided is 2 tier: Datasheet level, and Field level.

Being an open source alternative, I must said the features in APITable is impressive, and something we should really look forward.

In this article, I am going to show how we create a simpler CRM, and how to play around with the ACL with different collbarators.

Quick run-through

Pre-requisite check

  • Initial requirement

    Let’s look at how it started, as well as the initial design

  • URL

    https://apitable.com/

  • Platform

    APITable is open source project, it does provide cloud and self hosted solution

  • Cost

    It is an open source project, hence technically no cost to use the software, but you will have to pay for the cost of the infrastructure – server hosting.

Limitation

ACL provided by APITable is a great features, the only issue is, the Insert and Update permission are mixed together. I will show you how it post a possible issue in the tutorial below.

Let's get started

Invite Collaborators

Make sure the required personnel are invited to the space, we can invite by email, or link. The invite button is always located at the bottom-left. All the members will the similar permission initially. Admin able to further configure the permission at datasheet level.

Configure the tables

1. Create a datasheet. Let’s call it “customers”, and we create related fields based on article here. APITable come with a column type of “Member”, which allowed you select user as the value.

In our case here, 1 customer in-charge by 1 member.

 

2. This should be how the final datasheet look like

 

3. At the moment, APITable provide data import from Excel, as a new datasheet. No function to import data to “existing” datasheet yet. Luckily, copy and paste from Excel works well.

At the datasheet we just created, we copy and paste from the sample data here, hence assign the customers to Shane and Rick.

 

4. Next, let’s create 2 isolated views filtered for Shane and Rick. The purpose is to make, Shane and Rick only see the customers assigned to them only.

 

5. This is how the filtered view should look like. For the 2 views, let’s name is Shane’s Customers, and Rick’s Customers.

 

6. Here is the unique feature for APITable, which we need to create a “Mirrored” view from the view we just created. Let me explain a bit more how it works:

  • Datasheet, customers: This is the main datasheet, we only let admin access it, which we able to configure the permission on it.
  • View, Shane’s Customers / Rick’s Customers: These are the views inherited from main datasheet, customers. However, APITable don’t have the function to apply the permission here.
  • Mirrored View,  Shane’s Customers / Rick’s Customers: These are the mirrored views inherited from the Views we just create, and APITable allow admin to apply the permission here.

 

7. Now, let’s head back to the main datasheet, customers, we will apply the permission on the field “Assigned To”, so no one except admin able to update it.

We just need to remove the permission of “account’s Space”, as it indicate that everyone under “account’s Space”.

 

 

8. Now, time to apply permission for each mirrored view, and datasheet itself. First we just need to remove the permission for everyone in mirrored views.

 

9. Next, assign Rick to Rick’s Customers view, and assign Shane to Shane’s Customers view.

Let me explain a bit more on the permission.

  • Manager: Usually is the owner, or co-owner of the datasheet, as this role able to configure the mirrored view
  • Editor: Able to carry out entire CRUD operation on assigned mirrored view
  • Update-only, The only different with Editor is, not able to delete
  • Read-only: I don’t have to explain this, do I?

 

10. Make sure all the datasheet / views are properly protected with permission. CRM is relatively sensitive, as each sales personnel may rely on it for sales commission, hence protecting data from different personnel is important.

Let's try it out

1. To try out, login as Rick. You can see that Rick only able to see/manipulate the customer assigned to him

 

2. Let’s login as Shane, where Shane only able to see/manipulate the customers assigned to him as well.

 

3. Here is the catch, the “Insert record” option now available for Shane and Rick, and there is no way for me to switch if off. Here are the impact:

  • If Shane / Rick allowed to insert record: They will insert a record without “Assigned To”, due to it is only for admin
  • If Shane / Rick allowed to insert record and able to manage “Assigned To”: They might make a mistake, and set the “Assigned To” to someone else by mistake. Yes, you will be amazed what users will do sometime.

At this point of time, I am not able to set the default value based on login yet, hope we have a solution in near future on this.

 

4. Finally, the admin will have the overview of all customers, including latest update from Rick / Shane.

Despite of some limitations, APITable is still good enough for a simple CRM, especially when you have a small team, and need a some ACL control over the data. I am sure over the time, those limitation will be able to overcome by APITable soon.
Is it common for a company to assign leads to sales personnel by admin, and hide leads among sales personnel? I would say is case by case basis, usually is due to sales commission, or “high-profile” leads. I have seen this case before, and also seen the case where all the sales personnel able to see the same leads.
Leave a Reply

Your email address will not be published. Required fields are marked *

Prev
APITable: Web contact form in 5 minutes

APITable: Web contact form in 5 minutes

Looking for alternative to SeaTable or Airtable for web contact form?

Next
Busting Myths on Low Code/No Code: A Hilarious Journey Through Misconceptions & Magical Thinking

Busting Myths on Low Code/No Code: A Hilarious Journey Through Misconceptions & Magical Thinking

Explore the comical side of low code/no code myths as we debunk misconceptions,

You May Also Like
Total
0
Share