01 / OPERATING CONTEXT
The association's operating requirements.
A membership organization has several connected jobs to do. Member organizations submit information, administrators manage registrations and events, reviewers apply the rules, and members need dependable public information. Each group needs a different view of the work.
The build connects member-facing services with internal administration. A submission can affect a registration, a financial obligation, an official record and what appears on the public website. The software has to preserve those relationships through every handoff.
The platform brings those responsibilities into dedicated interfaces connected to a shared data foundation. Association rules shape the application behavior, including who can act, what needs review and when information is ready to publish.
02 / IMPLEMENTATION SCOPE
Application and service capabilities.
Portals for the people doing the work
Separate Member Portal, Operations Console, Web Administration and Registration applications give each role the forms, records and actions it needs.
Submissions through to official records
Ingestion, validation, review and finalization carry submitted information into the association's authoritative records, preserving decisions and supporting evidence.
Email connected to the workflow
Notifications connect a change in the system to the person responsible for the next step. Message content and destinations follow the relevant workflow.
A connected public experience
The public layer presents events, member-organization information and finalized records through controlled interfaces to the underlying data.
03 / ARCHITECTURE & TOOLS
System boundaries and the stack behind them.
A Google-stack platform connects purpose-built applications, existing Google workflows and a public website through a shared set of application services and data contracts.
Experience layer
React and TypeScript administrative applications, Firebase Hosting and a Webflow public website provide distinct interfaces for members, staff and public visitors.
Services and identity
Cloud Run services enforce application behavior and access boundaries. Google Identity Platform supports authenticated access. A separate anonymous public API exposes approved records, keeping public reads distinct from administrative commands.
Data and workflow foundation
BigQuery holds authoritative association records and publication-gated read models. Ingestion and retained Apps Script workflows carry source submissions into review. The email layer applies workflow-specific triggers, recipients and links.
Tools, frameworks and their roles
- React · TypeScript · Vite · React Router
- Separate administrative applications with typed interfaces, client-side routing and independently built frontends.
- Node.js · Google Cloud Run
- Application backends, the public API and communication services, with domain rules enforced at service boundaries.
- BigQuery · Cloud Storage · Secret Manager
- Authoritative records and serving views, object storage and managed runtime secrets.
- Firebase Hosting · Google Identity Platform
- Application delivery and identity integration for authenticated work surfaces.
- Google Apps Script · Gmail API · Webflow
- Retained Google workflows, the email-dispatch integration and the public website layer.
- Vitest · React Testing Library · Node.js test runner
- Frontend behavior and backend regression checks across the platform.
Domain logic, controls & engineering decisions
- Role-aware actions and server-side checks keep approval responsibility in the application services.
- Domain review and financial eligibility are separate state transitions. Payment gates finalization rather than blocking the reviewer from progressing the review.
- Idempotent financial write identifiers protect against duplicate records when a request is retried.
- Cash receipts can be allocated across event obligations, with balances recomputed by the service.
- Public views expose complete finalized records. The public interface renders persisted values without recalculating domain-specific classifications.
- Separate environments, automated validation and release controls cover application services, data contracts and public delivery.
04 / WORKFLOW WALKTHROUGH
From a member submission to a published record.
Submission processing shows how the portals, review rules, financial checks and public layer work together.
- 01
Submit and validate
A member organization supplies event information and supporting records. The intake process checks the submission and makes the work available for administrative review.
OUTPUTA submission with validation context - 02
Review and resolve
The reviewer inspects the supporting records, confirms the domain-specific review or returns the item for clarification. The next responsibility remains visible.
OUTPUTA recorded review and clear next action - 03
Confirm eligibility and finalize
Financial eligibility is checked before authoritative finalization. Review can proceed while an outstanding payment is resolved; publication follows the finalization rules.
OUTPUTAn approved, authoritative record - 04
Publish the approved record
The public service reads finalized records from the shared data platform, giving members access to approved information.
OUTPUTConsistent public information
05 / SYSTEM OUTPUTS
What the system produces.
The association has connected work surfaces for the people running it and a public layer fed by the same approved records. Operational responsibility is expressed in the software, from the first submission to publication.
- Registrations and event records
- Reviewed submissions and recorded decisions
- Financial allocations and eligibility checks
- Finalized records and public information