Product Registration Overview
Audience: Integration engineers who will onboard a new Team-based product under the Aventian umbrella.
This document uses Cleversort (a Jira-like project management product) as a concrete example while presenting rules, requirements, and best practices that apply to any product integrated with Aventian.
1. Minimum Requirements for a Product
To be eligible for integration, a product must satisfy these functional and architectural constraints:
Functional requirements
- Team-centric model — product data and access are scoped by
team(or organization). Every user action is performed in a team context. - Supports role/privilege enforcement — product must enforce access via roles and privileges provided by Aventian (not keep separate independent role store for same semantics).
- Redirect-friendly dashboard — product must accept team context (via query param or server-side SSO) and land the user on an appropriate team-scoped dashboard.
2. High-level Architecture
Per-Organization / Per-Team Product Databases
- Each subscribing organization (team) gets its own product database (for Cleversort, JotGo, etc.). These are isolated DBs so tenant data is not co-mingled.
- Product DBs are PostgreSQL instances. In the current deployment model:
- Per-team product DBs are provisioned dynamically (Dockerized Postgres containers running on GKE / VMs) at onboarding time.
3. Database Structure Requirements
Aventian provisions a team-scoped database for the product. The provisioning job will run your schema scripts and seed master data. The following are required patterns and expectations:
Naming & tenancy
- DB naming convention :
<team_key>It is unique for any team. So deterministic, collision-free team keys are used for DB naming. - Per-team isolation: each team has its own DB.
- Schema: every product will be added to the team database as a schema. For example if a team X has subscribed to Product y1 and y2, The team DB for team X will have schemas y1 and y2.