Adapting Strapi CMS for your implementation

Strapi is an open-source, API-first headless Content Management System (CMS) designed to manage structured data and expose it through RESTful services. In modern web development, Strapi excels by decoupling content management from the presentation layer. This allows teams to iterate on backend data models without requiring a full rebuild or redeploy of the frontend.

Why Strapi?

For this implementation, we required a solution that balanced developer flexibility with a user-friendly interface for operational teams. Key drivers included:

Dynamic Modeling: Seamlessly managing site registries, milestones, and build-date metadata.

Operational Autonomy: A built-in admin panel that allows non-technical users to manage data.

Workflow Automation: Leveraging Lifecycle Hooks to automate internal notifications.

Scalability: A robust plugin ecosystem for authentication and email integration.

Installation and Setup of Strapi

Prerequisites : Node.js ,npm

Our environment utilizes Strapi v5 configured with TypeScript for type safety, custom plugins, and advanced lifecycle logic.

# Initialize the project

npx create-strapi-app@latest my-project

To ensure environment consistency, the service is containerized via Docker:

• Internal Container Port: 1337

• External Host Port: 8008

  
  

Content Modeling

Data Architecture

We designed the schema to ensure data integrity while remaining flexible enough for changing project requirements.

Sites

1. Fields: site_name,dc_code, region, site_owner_name, site_owner_email

2. Purpose: Site registry and Site ownership attribution.

Milestone

1. Fields: display_name, sort_order, owner_person_name, owner_person_mail_id

2. Purpose: Dynamic milestone definitions and Milestone owner mapping.

Build Dates

1. Fields: site_name, dc_code, architecture, system_count, milestones

2. Purpose: Build scheduling records per site/DC.

Component in use

Milestone is a repeatable component attached to Build Dates.This structure supports dynamic milestone columns without redesigning the Build Date schema whenever milestone definitions change

•  display_name

•  date

•  risk_enabled

•  risk_notes (conditionally required when risk is enabled)

Authentication and Roles

Built-in authentication

The project includes Strapi authentication foundations through:

• Admin JWT secret configuration. 

• Users and permissions plugin dependency.

Strapi supports registration/login and JWT-based flows. In this project, authentication is especially relevant for admin workflows and role-driven data visibility.

Invitation and onboarding workflow

The project extends admin user provisioning through email invite logic:

• Admin invite is sent when the admin creates a user.

• Column owner invite is sent when milestone owner is assigned.

Site owner invite is sent when site owner is assigned.

Role-based access control used in project logic:

The admin UI differs by role in two major ways:

• Left navigation visibility for collection types.

• Data-level visibility in Build Dates (row filtering and milestone filtering).

Custom role-sensitive filtering is implemented in Build Date lifecycles:

•  Super Admins receive unrestricted access.

•  Site owners are filtered to their owned sites.

•  Milestone owners are filtered to assigned milestones.