1.Introduction
When designing a super app, one of the most fundamental challenges from both an architectural and scalability perspective is establishing robust authorization and authentication across all users, groups, and roles. This becomes even more critical when we’re building a no-code super app platform—a system designed to generate an endless number of future super apps.
In such a scenario, we cannot predict what kinds of access restrictions a future app designer might implement. That’s why the architecture must support Turing-complete role logic, layered permission hierarchies, and geolocation-based controls to enforce precise and dynamic access rules.
In today’s article, we’ll explore the second part of Claim #2 from the ACENji No-Code Software Development Platform patent, which focuses on access hierarchy and permission logic:
“2. The no-code software development platform of claim 1 wherein users may at least one or more of use a template, create a template, and forgo templates, wherein created templates may further be made available to at least one or more of individuals, groups, and members within an authorization hierarchy, the groups further determined by at least one or more of individual identity, group identity, assignment identity, and geolocation features.”
We previously covered the first half of this claim in our article Building Super Apps with Templates in No-Code Platforms, focusing on:
“…users may at least one or more of use a template, create a template, and forgo templates…”
Today, we’ll focus on the second half of the claim:
“…wherein created templates may further be made available to at least one or more of individuals, groups, and members within an authorization hierarchy, the groups further determined by at least one or more of individual identity, group identity, assignment identity, and geolocation features.”
2. Why Access Control Matters in Super Apps
For any app to scale to millions of users—especially a super app—access control becomes one of the most critical components of the architecture. Without a well-designed system of roles, permissions, and access rules, even the most innovative app can hit a wall.
Imagine you’ve built a feature-rich super app. It reaches three million daily active users, only to reveal that access logic has become so tangled that it’s impossible to expand, maintain, or secure. What do you do then?
Now, let’s take it a step further. If your super app is built with 100% no-code, like in ACENji, the creativity of the app designer becomes the main driver. But with that creative power comes complexity—especially when multiple types of users need to interact with the app in different ways.
Before diving into user roles, let’s quickly define the types of super apps we’re referring to:
3. Types of Super Apps You Can Build with ACENji
3.1 Web Super Apps
Accessible via browsers, optimized for responsive web experiences. Useful for public-facing or enterprise dashboards.
3.2 Mobile Super Apps (iOS & Android)
Native or hybrid apps that combine multiple services—like messaging, payments, and bookings—into one downloadable experience.
3.3 TV Super Apps
Designed for smart TVs or streaming boxes (like Roku or Apple TV), these offer unified experiences for content, shopping, or smart home control.
4. Common User Types in Super App Architectures
4.1 Super App Admin
The top-level administrator of the app builder —can manage roles, features, templates, and settings across all super apps.
4.2 Super App per Account Admin
The owner creator of the super app instance on the ACENji platform. Oversees team members and platform-level settings.
4.3 Super App Platform Instance Assigned User
An end user granted access to the ACENji generated Super platform by an admin. They can work across projects, apps, and templates.
4.4 Mini-Apps Only User
A user assigned access to specific mini apps. They do not have visibility into the broader platform—ideal for focused use cases.
There could be hundreds of variations based on the top-root roles.
4.5 Self-Registered User to a Super App Instance
A user who signs up directly through the Super app’s web or mobile interface. Access is granted based on project-specific logic and onboarding flows.
4.6 Guest to a Super App
Yes, there are users like that: an unauthenticated, unregistered user. May access limited public-facing content or features (e.g., product preview, booking lookup, or trials).
5. Roles and Permissions in No-Code Platforms
What Are Roles & Permisisons?
Roles define what a user can do. They act as permission bundles. For example:
- Admin – Can create/edit/delete everything
- Editor – Can create and modify content, but not users or settings
- Viewer – Can only view content
In ACENji, roles are defined inside the app configuration itself—whether via UI, using bulk import via flat file. They are not hardcoded, which means creators can:
- Define new roles as needed (e.g., “Manager,” “Vendor,” “Technician”)
- Assign roles globally or on a per-mini-app basis
- Combine roles with conditions like geolocation or group membership
But before we address more about the roles, let’s define Permissions.
What Are Permissions?
Permissions are the specific actions a user can take, such as:
- Access a specific page or component
- Submit a form
- View analytics data
- Modify user profiles
We take the creation of permissions very seriously, and by default in a super app—there are none.
Wait, what?
Yes. The reason there are none is because we want to give the user the ability to define them as a hierarchy with multiple nodes. Think of a node-leaf model, where there is a tree with branches (hierarchy) and eventually leaf nodes with final destinations.
Permissions can be applied to branches and leaves. They can be applied to individual users, groups, roles, mini apps, or even features, pages, tiles, and templates.
6. How to Blend Permissions and Roles
Super app admins can apply a bulk merge between numbers of users or groups to permission tree branches.
This defines the level of permission.
Upper levels win over lower levels in case of conflict.
7. How Geolocation Applies to Super App Permissions
Super apps are all about geolocation. In fact, today, all super apps are geolocation-restricted. That could be based on country boundaries, continent, cellphone carrier, or any combination.
With ACENji, we are adding stricter permission control by applying geolocation to permission tree branches, where each branch can have a geofence. That’s pretty cool.
Example: Super App with Geo-Based Access for a Healthcare System
Let’s say your no-code super app operates in the healthcare/emergency sector, covering all 50 U.S. states. Each level of the system supports access control using a geolocation hierarchy. As we go deeper into the hierarchy, permissions become more granular.
Hierarchy Table:
| Level | Count | Sample Values |
| States | 50 | Michigan, California |
| Counties | 250 | Kent County, Oakland County |
| Towns / Cities | 2,000 | Grand Rapids, Wyoming, Troy, Ann Arbor |
| ZIP Codes | 6,000 | 49503, 49509, 48084 |
| Facilities / Buildings | 10,000 | Mercy Health Main, Spectrum East |
| Floors | 50,000 | Floor 1, Floor 2, etc. |
| Rooms | 400,000 | Room 101, Room 302A |
| Beds | 600,000 | Bed A, Bed B (inside rooms) |
Example Path:
State: Michigan
→ County: Kent County
→ City: Grand Rapids
→ ZIP: 49503
→ Building: Mercy Health Main Campus
→ Floor: Floor 3
→ Room: 302A
→ Bed: 302A-B
Geofence (Applied at Each Level)
| Level | Geofence Logic | Example Coordinate Range |
| City | All within Grand Rapids limits | { “type”: “Polygon”, “coordinates”: [[[…]]] } |
| ZIP Code | 49503 zone | { “type”: “Polygon”, “coordinates”: [[[…]]] } |
| Building | Mercy Main Campus only | { “type”: “Polygon”, “coordinates”: [[[…]]] } |
| Room | Indoor mapping if supported | Coordinates paired with internal mapping data |
Each level restricts access to users within that defined area:
- Emergency responders with floor-specific access
- Facility admins with building or county-level permissions
- Health inspectors scoped by city, ZIP, or building level
Declarative Rule Example (Conceptual)
A nurse is assigned to only Floor 3 of Mercy Health Main. Their access is defined declaratively in the platform using geo-tagged hierarchy fields.
8. Is Geolocation Real When Applied?
Yes—but with important nuances.
✅ Geofence Is Optional by Default
Geolocation is entirely optional. You can structure access via hierarchy even if no physical location verification is used.
🧩 Partial Permissions Across the Hierarchy
You can apply permissions selectively:
- A user may access all buildings in Kent County, but only one floor in Grand Rapids
- Another may access all rooms on Floor 2 of a building, but nothing else
📍 Geolocation Becomes Real with User Devices
When users carry mobile devices:
- Location can be physically verified (via GPS)
- Access becomes context-aware, not just credential-based
Examples:
- A nurse has permissions only while physically inside the hospital
- An inspector may be blocked from logging in outside their approved ZIP code
9. Why No-Code Makes This Scalable
The ACENji platform allows all this to be defined declaratively, not programmatically.
| Traditional | No-Code (ACENji) |
| Backend logic for access control | Visual permission builders |
| Hard-coded rules | Configurable rules via JSON or UI |
| App redeployment required for updates | Live updates, no redeployment needed |
| Complex scaling logic | Hierarchical scaling built-in |
No-code doesn’t mean limited. It means accessible, scalable, and smart.
10. Wrap-Up: Intelligent Access at Scale
As super apps grow in complexity and scale, access control evolves from a technical need to a strategic advantage.
By combining:
- Role-based permissions
- Group and assignment logic
- Geolocation enforcement
- Structured, layered hierarchy
…you build a system that’s secure, dynamic, and future-proof.
ACENji embraces this philosophy in full. Whether you’re creating a super app for healthcare, logistics, or enterprise tools—your access logic will grow with your users, not against them.
Want to learn more about super apps?
Check out: What Is a Super App?
Thanks for reading
By Ivan Assenov
