Submissions
Purpose and Outcomes
Submissions gives a customer one place to organize review work that otherwise spreads across application records, reviewer correspondence and staff decisions. It connects the people who supply evidence, the people who assess it and the application that acts on the result. A customer can use that shared arrangement for work such as awards, nominations or reports while keeping the underlying business record with its owning application.
The area gives staff a common language for review responsibility and a retained account of the evidence behind an outcome. Administrators govern the review arrangement, coordinators oversee daily work, reviewers contribute judgment, and readers inspect progress. Applicants and contributors supply the material the review needs. Owning applications and scheduled work participate through service integrations rather than interactive staff screens.
The intended outcome is a review that staff can explain and an outcome whose handling the owner can account for. Delivery evidence, outstanding work and ownership boundaries matter alongside the decision itself. The current area describes the standalone engine and its staff console. Applicant and contributor backends exist before their portal experiences. Product has approved moving form collection and review into Platform, so this overview keeps that future ownership visible without presenting the migration as completed.
Scope and Boundaries
Submissions owns the shared review arrangement and its local evidence: application content, reviewer work, contributor material, outcomes and follow-up records. It also keeps the delivery state needed to distinguish recording a decision from the owner handling it.
Platform supplies identity and access policy, workspace lifecycle, prepared files, communication delivery, attention, governed queries and shared workflow primitives. CRM supplies contact and organization records and owns requested tasks. The console shell supplies navigation and hosts staff screens. Each owning application keeps its domain records and performs the business effects of a review outcome. Integration requests and acknowledgement cross these boundaries; the area does not establish that a requested external effect succeeded merely by recording local work.
How the Area Is Divided
The Submissions, Intake, Review and Outcomes module is the area's single corpus module. It brings the review arrangement, collected evidence, assessment work, outcomes and operational visibility together. Open it when a question concerns the meaning of a review record, responsibility for review work, the staff experience or a handoff to the application that owns the business record. Its design distinguishes configuration, intake, review, outcomes and reporting service responsibilities within that shared module.
Area-Level Invariants
Review responsibility and business ownership remain separate throughout the area. Workspace boundaries and the relevant process or participation constrain access across its records. Shared services retain their own responsibilities, and local records provide evidence of a handoff rather than an unconditional promise of external completion. The standalone engine remains the current implementation record until the Platform move is verified.
Open Ownership Questions
The module's existing ownership questions cover where staff configure review after the Platform move, where owner-hosted applications collect answers during the form transition, and when the corpus changes to the new homes. They also ask whether local action history remains sufficient and who compensates effects already performed when an application ends or reopens. Those decisions remain with Product; this overview preserves their existing home.