Submitting a project for approval
Once a producer has filled in a project’s details, episodes, and contributors, they can submit it for approval by one of the commissioning funders. The funder receives an email and uses the approving-a-project flow to verify or reject it.
What happens
Section titled “What happens”sequenceDiagram
actor Producer
participant App as Your app
actor Funder
Producer->>App: Open project, click "Get verified"
App-->>Producer: Verification form (select funder)
Producer->>App: Choose funder, submit
App-->>Producer: Warning modal — confirm requirements met
Producer->>App: Confirm
App->>App: Mark project as SUBMITTED
App->>Funder: Email with link to approve/reject
What the user sees
Section titled “What the user sees””Get verified” button
Section titled “”Get verified” button”The save bar at the bottom of the project’s detail page shows a “Get verified” button (Projects.project-registration.get-verified-button). Clicking it opens a side form.
Verification form
Section titled “Verification form”| Visible text | Translation key |
|---|---|
| Form title | Projects.request-verification.title |
| Funder select field | Projects.request-verification.subscriber-input-label (with tooltip Projects.request-verification.subscriber-tooltip) |
Only commissioner-tier funders appear in the dropdown, and only those already listed as funders on the project. If there are none, the form closes automatically.
Warning modal
Section titled “Warning modal”Before the submission actually fires, a modal appears summarising what the producer is confirming. Translation keys:
| Part | Key |
|---|---|
| Modal title | Projects.request-verification.warning-modal.title |
| Intro | Projects.request-verification.warning-modal.content-intro |
| Requirement bullets | Projects.request-verification.warning-modal.requirement-1, requirement-2 |
| Outro | Projects.request-verification.warning-modal.content-outro |
The producer confirms; the project’s status flips to “submitted” and the funder gets an email.
Outcomes
Section titled “Outcomes”| Outcome | What happens |
|---|---|
| Success | Form and modal close; a success toast appears (currently English-only — see Known gap) |
| Failure | Error toast with the underlying message |
What you can customise
Section titled “What you can customise”Translations
Section titled “Translations”All verification UI text lives under Projects.request-verification.* in tep-configuration/translations/{locale}/main/projects.json. Override per client in clients/{client}/translations/{locale}/overrides.json.
The verify-project email
Section titled “The verify-project email”The funder receives a verify-project email. You can override the template per client by providing {client}-verify-project.mjml; otherwise you inherit tep-verify-project.mjml.
Variations for your deployment
Section titled “Variations for your deployment”The flow is the same across all clients. Differences are only in translations and the verify-project email template.
Need more detail?
Section titled “Need more detail?”For the funder filter logic, the warning-modal orchestration, and the mutation, see Submitting for approval (engineering).