Program Configuration Confirmation

Process documentation extracted from code comments (strapi-docker).

Process Overview

Property	Value
Process ID	`PROGRAM-CONFIGURATION-CONFIRMATION`
Owner Teams	@team-platform
Repositories	platform, strapi-docker
Total Steps	8
Handoff	N/A

Process Flow Diagram

Step-by-Step Breakdown

The user has reviewed the configuration in the confirmation modal and clicks Confirm. This locks the configuration so it can no longer be edited and saves it. The system then checks whether learning groups (batches) already exist and creates them if not.

✅ Explicit Repository: platform Location: src/components/growthkit/ConfirmConfigurationButton.tsx:36

Triggers: Step PROGRAM-CONFIGURATION-CONFIRMATION:1.1

👤 Step 1.1: Validate deal, confirm and save

The system checks that a HubSpot deal is linked, marks the configuration as confirmed with the current date and time, and saves it to the server. The configuration becomes read-only after this.

✅ Explicit Repository: platform Location: src/components/growthkit/ConfirmConfigurationButton.tsx:52

Triggered by: Step PROGRAM-CONFIGURATION-CONFIRMATION:1.0 Triggers: Step PROGRAM-CONFIGURATION-CONFIRMATION:1.2, 1.3, 2.0

💻 Step 1.2: Store confirmation in memory

The system stores that the configuration is confirmed and records the exact date and time. This happens in memory first; the actual save to the server follows in the next step.

🔄 Implicit Repository: platform Location: src/hooks/useProgramConfiguration.tsx:450

Triggered by: Step PROGRAM-CONFIGURATION-CONFIRMATION:1.1

Side Effects:

Modifies programConfiguration.json.confirmed

🌐 Step 1.3: Send configuration to server

The confirmed configuration (including the new flag and timestamp) is sent to the server and stored permanently. The user sees a success message when done.

🔄 Implicit Repository: platform Location: src/hooks/useProgramConfiguration.tsx:472

Triggered by: Step PROGRAM-CONFIGURATION-CONFIRMATION:1.2 Triggers: Step PROGRAM-CONFIGURATION-CONFIRMATION:2.0 (Backend receives request)

💻 Step 1.4: Check for existing batches

After the configuration is confirmed and saved, the system checks whether any learning groups (batches) already exist for this program. This determines whether new ones need to be created.

🔄 Implicit Repository: platform Location: src/components/growthkit/ConfirmConfigurationButton.tsx:67

Triggered by: Step PROGRAM-CONFIGURATION-CONFIRMATION:1.1

💻 Step 1.5: Create initial batches

If no learning groups exist yet, the system creates the initial ones based on the confirmed configuration (e.g. number of participants and group size). The batch list is then refreshed.

🔄 Implicit Repository: platform Location: src/components/growthkit/ConfirmConfigurationButton.tsx:85

Triggered by: Step PROGRAM-CONFIGURATION-CONFIRMATION:1.4

Condition: Only executes if existingBatches.length === 0 Side Effects:

Creates batch records, triggers batch reload

⚙️ Step 2.0: The server receives the confirmed configuration from the frontend (PUT request).

This is handled by Strapi’s default update flow; the lifecycle hooks below run as part of that update.

🔄 Implicit Repository: strapi-docker Location: src/api/program-configuration/content-types/program-configuration/lifecycles.js:8

Triggered by: Step PROGRAM-CONFIGURATION-CONFIRMATION:1.3 (frontend save)

🔄 Step 2.1: Runs before every program-configuration update, including confirmation.

Compares incoming data with stored data and adds a change history entry (timestamp, changes, user) when something has changed.

🔄 Implicit Repository: strapi-docker Location: src/api/program-configuration/content-types/program-configuration/lifecycles.js:327

Triggered by: Step PROGRAM-CONFIGURATION-CONFIRMATION:2.0 (API receives PUT)

Explicit vs Implicit Actions

Understanding which actions are user-initiated versus automatic is crucial for troubleshooting.

✅ Explicit Actions (User-Initiated)

No explicit actions documented.

🔄 Implicit Actions (Automatic)

No implicit actions documented.

Triggers

No triggers documented.

Side Effects

No side effects documented.

Error Handling

No error handling documented.

Testing

No testing information documented.

Monitoring & Debugging

No monitoring information documented.

No related processes documented yet.

Code References

Step 1.0 - Frontend (platform)

File: src/components/growthkit/ConfirmConfigurationButton.tsx Line: 36

Description: The user has reviewed the configuration in the confirmation modal and clicks Confirm. This locks the configuration so it can no longer be edited and saves it. The system then checks whether learning groups (batches) already exist and creates them if not.

Step 1.1 - Frontend (platform)

File: src/components/growthkit/ConfirmConfigurationButton.tsx Line: 52

Description: The system checks that a HubSpot deal is linked, marks the configuration as confirmed with the current date and time, and saves it to the server. The configuration becomes read-only after this.

Step 1.2 - Frontend (platform)

File: src/hooks/useProgramConfiguration.tsx Line: 450

Description: The system stores that the configuration is confirmed and records the exact date and time. This happens in memory first; the actual save to the server follows in the next step.

Step 1.3 - Frontend (platform)

File: src/hooks/useProgramConfiguration.tsx Line: 472

Description: The confirmed configuration (including the new flag and timestamp) is sent to the server and stored permanently. The user sees a success message when done.

Step 1.4 - Frontend (platform)

File: src/components/growthkit/ConfirmConfigurationButton.tsx Line: 67

Description: After the configuration is confirmed and saved, the system checks whether any learning groups (batches) already exist for this program. This determines whether new ones need to be created.

Step 1.5 - Frontend (platform)

File: src/components/growthkit/ConfirmConfigurationButton.tsx Line: 85

Description: If no learning groups exist yet, the system creates the initial ones based on the confirmed configuration (e.g. number of participants and group size). The batch list is then refreshed.

Step 2.0 - Backend (strapi-docker)

File: src/api/program-configuration/content-types/program-configuration/lifecycles.js Line: 8

Description: The server receives the confirmed configuration from the frontend (PUT request). This is handled by Strapi’s default update flow; the lifecycle hooks below run as part of that update.

Step 2.1 - Backend (strapi-docker)

File: src/api/program-configuration/content-types/program-configuration/lifecycles.js Line: 327

Description: Runs before every program-configuration update, including confirmation. Compares incoming data with stored data and adds a change history entry (timestamp, changes, user) when something has changed.

Team Handoff Details

No team handoff information documented.

Process Overview​

Process Flow Diagram​

Step-by-Step Breakdown​

👤 Step 1.0: User confirms in modal​

👤 Step 1.1: Validate deal, confirm and save​

💻 Step 1.2: Store confirmation in memory​

🌐 Step 1.3: Send configuration to server​

💻 Step 1.4: Check for existing batches​

💻 Step 1.5: Create initial batches​

⚙️ Step 2.0: The server receives the confirmed configuration from the frontend (PUT request).​

🔄 Step 2.1: Runs before every program-configuration update, including confirmation.​

Explicit vs Implicit Actions​

✅ Explicit Actions (User-Initiated)​

🔄 Implicit Actions (Automatic)​

Triggers​

Side Effects​

Error Handling​

Testing​

Monitoring & Debugging​

Related Processes​

Code References​

Step 1.0 - Frontend (platform)​

Step 1.1 - Frontend (platform)​

Step 1.2 - Frontend (platform)​

Step 1.3 - Frontend (platform)​

Step 1.4 - Frontend (platform)​

Step 1.5 - Frontend (platform)​

Step 2.0 - Backend (strapi-docker)​

Step 2.1 - Backend (strapi-docker)​

Team Handoff Details​