This is week seven of the SwarmCraft workflow replacement case-study series. SwarmCraft used an AI build agent to turn a complex cross-system training brief into a 41-ticket, production-shaped application with a working browser experience, API, database migrations, integration boundaries, automated tests, deployment contracts, runbooks, and screenshot evidence.
The result is an AI Training Operations console that brings two well-known systems—BambooHR and Trainual—into one governed employee training workflow. A hire, role change, location change, or policy update can become a source-backed training plan. The AI-assisted planning workflow brings relevant Trainual evidence, gaps, proposed assignments, due dates, and rationale into one reviewable packet. A training coordinator stays in control, and only approved work can cross the guarded Trainual writeback boundary.
This is much more powerful than another training dashboard. The application combines signed employee-lifecycle intake, permission-scoped MCP retrieval, human approval, idempotent assignment writeback, employee and manager workspaces, content-impact review, connector health, exception handling, overdue follow-up, and a printable evidence packet. It turns a fragmented HR-and-training handoff into an observable workflow that can explain what the AI proposed, what a person decided, what reached Trainual, and what happened next.
The target is deliberately narrower than “build an LMS.” Trainual remains the source of truth for published training content, assignments, completions, and profile documents. BambooHR remains the source of truth for employee identity, employment status, manager, role, department, and location. The owned software sits between them, where assignment planning, exceptions, overdue follow-up, evidence, and human decisions otherwise scatter across spreadsheets and messages.
That boundary matches Trainual's own description of what Trainual is and what it is not: a connected training, knowledge, and operations platform, not a replacement for the HRIS or a full project management tool. It also matches Trainual's current integration surfaces. The Trainual MCP server provides permission-scoped, read-only context for external AI tools, while Trainual's API and webhooks provide the developer path for retrieval, assignment changes, completion data, and event-driven integrations.
If you are still deciding which category product fits, start with Best learning management system. This article is the implementation-led view: what training workflow automation looks like when the source systems stay put and the coordination layer becomes owned software.
Project stats
| Stat | Week 07 result |
|---|---|
| Implemented tickets | 41 |
| Final board state | 41 done / 0 open |
| Build runner | OpenAI Codex CLI |
| Agent requests | 41 |
| End-to-end driver runtime | 4h 25m |
| Build-lane runtime | 4h 23m |
| Tracked files | 213 |
| Tracked text lines | 26,585 |
| Test and spec files | 44 |
| PostgreSQL migrations | 10 |
| Playwright browser scenarios | 24 passing |
| System-test evidence screenshots | 9 |
| SwarmCraft setup screenshots | 2 |
Those numbers reflect a substantial build rather than a thin interface prototype: 41 tickets closed, 213 tracked files, 10 database migrations, 44 test and spec files, 24 passing browser scenarios, and no open or blocked work on the final board.
The useful result is not a generated training dashboard. It is a repository with employee lifecycle intake, permission-aware Trainual context retrieval, a training workflow policy, human decision endpoints, guarded assignment writeback, integration retry state, append-only evidence, role-aware browser screens, production configuration, tests, and runbooks.
The employee training workflow we built
The finished application supports five accountable roles.
| Role | Responsibility |
|---|---|
| Employee | Reviews assigned learning, timing, approved exceptions, and effective-dated history without editing the source record. |
| People manager | Reviews team readiness, overdue work, upcoming deadlines, and escalation state. |
| Training coordinator | Reviews source-backed proposals, records approval or rejection, and controls whether an approved assignment can proceed to writeback. |
| Content owner or compliance lead | Reviews content impact, policy evidence, and audit history. |
| HR operations administrator | Oversees lifecycle intake, connector health, exceptions, and evidence packets across systems. |
The implemented employee training process follows this operating sequence:
- A signed BambooHR lifecycle event identifies an employee hire, update, or termination using an opaque employee reference.
- The API verifies the raw request with HMAC-SHA256 before it normalises or stores the event.
- A replay-safe PostgreSQL inbox deduplicates deliveries and records processing, retry, or dead-letter state without retaining the raw employee payload.
- The Trainual read boundary searches approved content through two allow-listed MCP operations and normalises each result into a citable source reference.
- The workflow represents a proposed assignment plan with sources, uncertainty, due dates, recurrence, and a plain-language rationale.
- The training coordinator reviews that proposal and can approve, reject, or ask for more information.
- Approval and writeback remain separate actions. The writeback executor rejects any assignment mutation unless both the request and item are approved.
- The Trainual API adapter uses its own least-privilege token, requires an idempotency key, retries transient failures, and reconciles removals.
- Employees, managers, coordinators, content owners, compliance leads, and HR operations users see only the work allowed by their application capability.
- The evidence surface separates AI suggestions, human approvals, API writebacks, webhook activity, reminders, and exceptions so later reviewers can reconstruct the workflow.
This is the difference between employee training automation and a reminder script. The software has to preserve source-system authority, expose uncertainty, wait for a person at the decision boundary, and show what happened after approval.
The coordinator queue is the training operations surface
Most training workflow automation fails between “this employee needs training” and “the assignment was correctly recorded.” The coordinator has to reconcile the employee change, current responsibilities, training content, prior completion, effective dates, exceptions, and due-date policy before acting.
The Week 07 queue puts those facts in one review surface.
The pending view shows the employee reference, cited Trainual sources, uncertainty notes, proposed assignments, rationale, and the decision controls in the same reading order. The fixture is deterministic and contains no real employee data.
That distinction matters for AI-assisted training. A suggestion is useful only when the coordinator can inspect the evidence behind it and see what is missing. The target app implements the proposal, provenance, and review contract with deterministic data; it does not claim that a live model provider was connected during this run.
Human approval and Trainual writeback are different states
A weak training approval workflow treats the approval click as proof that the external assignment succeeded. The Week 07 build does not.
The coordinator review first changes the plan's human decision state. Only then does the separate Trainual writeback control become available.
The server-side boundary enforces the same rule. A writeback command must contain an approved request, an approved item, stable identifiers, an assignment action, and an idempotency key. Transient failures become retry_pending; validation and non-retryable failures become terminal failures. Assignment removal is followed by reconciliation rather than assumed successful.
This is an important LMS workflow automation pattern: the application may own the decision and retry state while Trainual still owns the assignment and completion record.
Approval and rejection remain reviewable
The API-backed workflow proves both paths. A manager can create a request, approve it, and see the recorded outcome rather than losing the item when it leaves the pending queue.
Rejection is equally explicit. The read-only reviewer sees the rejected request, its previous pending state, and the reason that the evidence was insufficient.
That negative path is operational evidence, not an edge-case decoration. Training records workflows need to explain why work did not proceed, especially when a later role change, content update, or exception reopens the decision.
What the custom training workflow includes
| Capability | What was implemented | Boundary kept intact |
|---|---|---|
| BambooHR lifecycle intake | Signed lifecycle endpoint, normalisation, replay protection, retry state, and deterministic tests | BambooHR remains the employee source of truth; the app does not recreate provisioning. |
| Trainual MCP context | Two allow-listed read operations, permission checks, citations, and partial/unavailable states | MCP is read-only and no live vendor transport or credential is bundled. |
| Training workflow policy | Explicit request/item states, freshness rules, approval routing, exceptions, and policy reason codes | Policy evaluation cannot mutate a vendor record. |
| Coordinator review | Filterable proposals with sources, uncertainty, assignments, human decision controls, and separate writeback affordance | The coordinator demonstration screen does not pretend a vendor mutation occurred. |
| Trainual assignment writeback | Approval guard, separate API credential, idempotency keys, bounded retry, and reconciliation | Trainual continues to own assignments and completions. |
| Employee workspace | Active assignments, progress, timing, exception state, and effective-dated history | It does not become a course player or employee directory. |
| Manager dashboard | Readiness trends, overdue items, upcoming deadlines, and escalation state | Managers cannot rewrite training records from the dashboard. |
| Content impact | Draft content changes mapped to affected roles, assignments, and plans | Publishing remains in the content system. |
| Evidence and audit | Provenance-grouped timeline, request audit, source links, state changes, and printable evidence packet | The surface is read-only; corrections happen in the owning workflow or source system. |
| Connector health | Healthy, warning, failed, disabled, timeout, and operator-action states | Credentials and connector payloads stay server-side and out of logs. |
| Role access | Capability-aware navigation plus server-enforced protected operations | Hidden navigation is not treated as authorization. |
Technology implemented
| Layer | Week 07 implementation |
|---|---|
| Browser application | React 19 and Vite, with responsive role-specific operations screens |
| API | Node.js HTTP service with explicit authorization, workflow, connector, and audit modules |
| Persistence | PostgreSQL with 10 versioned Flyway SQL migrations |
| Identity | OpenID Connect configuration and deterministic authenticated browser fixtures |
| HRIS integration | BambooHR lifecycle adapter and HMAC-verified webhook ingestion |
| Training context | Permission-scoped Trainual MCP read adapter with deterministic mocks |
| Training mutation | Separate Trainual API assignment adapter with approval and idempotency guards |
| Assurance | Append-only security, workflow, connector-attempt, and state-history records |
| Delivery | Docker images, local and production Compose contracts, health checks, and recovery runbooks |
| Verification | Node unit/integration tests and 24 Playwright browser scenarios |
What the browser evidence proves
The target repository's screenshot command drives the production browser bundle against a deterministic, stateful API fixture. It creates and decides requests, signs in as seeded roles, reloads persisted evidence views, and writes nine stable screenshots.
The audit view shows that a workflow is more than its current status. A reviewer can follow the proposal, human decision, and state changes in order.
The evidence packet goes further by separating provenance. AI-generated suggestions, human decisions, Trainual writeback results, webhook events, reminder outcomes, and exceptions are visually and textually distinct.
The browser suite also proves the denial path. A manager who opens the compliance audit route receives a clear access-denied screen rather than hidden data or a misleading empty state.
The 24 scenarios cover authenticated navigation, role-specific routes, request creation, approval, rejection, coordinator review, audit inspection, persisted evidence, connector status, mobile navigation, tablet layouts, narrow-screen overflow, semantic landmarks, labelled controls, and keyboard-visible interactive elements.
How SwarmCraft structured the build
The scenario unlocked an AI Training Operations project with 41 tickets. The initial board grouped the work across repository foundations, identity, database migrations, integration boundaries, workflow policy, APIs, browser surfaces, evidence, deployment, and final verification.
The board screenshot is the initial plan, not the final status. The build-lane manifest is the final evidence: 41 tickets selected, 41 tickets done, zero open, zero blocked, and zero manual-review outcomes.
That sequencing is why the finished repository has more than a UI. The work established the trust boundaries first, then built the workflow states and connector behavior, then added role surfaces, evidence, accessibility, deployment, and browser proof.
What must be true before you retire the training platforms
Course authoring, learning delivery, assessments, catalogues, certifications, completion records, learner portals, employee data, and training operations do not have to remain one buying decision. Keep the LMS and HRIS during discovery and parallel operation while the team decides which records and workflows it will own, which specialist delivery services still earn their place, and which bundle features are not part of the real operation.
Trainual is especially credible when the job is documenting the business playbook, onboarding people consistently, assigning process and policy training, tracking progress, and keeping responsibilities visible. Its MCP server, currently available on Premium and Enterprise plans, also gives external AI tools a permission-scoped way to search training content, users, groups, assignments, responsibilities, software records, and profile documents without opening a write channel.
The cross-system operating loop is the first useful exit boundary when:
- BambooHR role changes do not become one reviewable training plan
- coordinators repeatedly reconcile employee context with Trainual content and completions
- proposed assignments need evidence citations and an uncertainty state
- approval, writeback, and writeback success are being treated as the same event
- leave, extensions, exemptions, failed assessments, and overdue escalation live outside the training record
- managers and coordinators need one shared follow-up queue
- auditors need an evidence packet that connects source content, assignment, decision, completion, exception, and connector outcomes
- the team can keep Trainual and BambooHR as temporary source systems while it proves the owned operating loop
Before removing either incumbent, run role changes, plans, approvals, writebacks, exceptions, and completion evidence in parallel. Reconcile the records, prove recovery, and decide deliberately where course content, learning delivery, employee facts, and training history will live after each cutover.
The focused workflow is therefore a migration wedge, not a permanent instruction to keep both platforms. Once it operates reliably, the team has real evidence for the next ownership boundary. When that wider record and migration decision is still uncertain, Deep Discovery can shape the staged exit with less change risk.
For the broader buying and switching context, continue with Best learning management system, Why training software sprawl creates more admin than learning, and Trainual replacement.
What this says about AI-built workflow software
The useful AI role in this employee training workflow is bounded and reviewable:
- retrieve permitted training context
- compare a lifecycle change with role and completion evidence
- propose assignments and due dates
- cite the source records used
- expose missing or uncertain evidence
- draft a rationale and next action
- wait for an accountable human decision
- hand only approved work to the writeback adapter
- preserve the proposal, decision, connector outcome, and later override as separate evidence
The AI should not autonomously assign training, approve an exception, send a sensitive escalation, or make an employment decision. Retrieved content is evidence, not an instruction that can override policy or call a tool.
The Week 07 repository implements the contract around that future model call: typed context boundaries, citations, provenance, review states, authorization, writeback guards, retry behavior, and audit evidence. That makes a later AI-provider connection safer and replaceable instead of embedding model behavior inside business policy.
What operator-builders should take from week seven
The biggest lesson from week seven is not that AI can recommend training. It is that a focused, owned application can turn two capable but separate platforms into one accountable operating workflow without pretending to replace either of them.
That workflow can listen for authoritative changes in BambooHR, retrieve permitted evidence from Trainual, use AI to assemble and explain a proposed plan, pause for accountable human judgement, and carry only approved work across a guarded writeback boundary. Exceptions, retries, overdue follow-up, and audit evidence stay visible instead of falling back into spreadsheets, inboxes, and memory.
For operator-builders, the design rule is simple: map authority before automation. Decide which system owns each fact, which decisions require a person, which AI outputs need citations, and what the workflow must do when an integration fails. AI becomes genuinely powerful when it compresses the messy synthesis work without being allowed to blur ownership or accountability.
That is what makes week seven more than a training demo. It is a reusable pattern for cross-system operational software: preserve the trusted records, own the workflow between them, and make every proposal, decision, mutation, exception, and recovery step explainable.
BambooHR keeps the people facts. Trainual keeps the training facts. The business gains the part neither product can own for it: the way its work actually moves.
