Approving or rejecting a project
This is the funder-side counterpart to Submitting a project for approval. The funder receives the email, opens the project, and decides.
What happens
Section titled “What happens”sequenceDiagram
actor Funder
participant App as Your app
actor Producer
Producer->>App: Submits project (see "Submitting for approval")
App->>Funder: Email with link to project
Funder->>App: Open link, view project
Funder->>App: Click "Verify" or "Reject"
alt Reject
App-->>Funder: Modal asking for reason
Funder->>App: Enter reason, confirm
end
App->>App: Status → APPROVED / REJECTED
App->>Producer: Email with the outcome
What the funder sees
Section titled “What the funder sees”The verification panel on the project page
Section titled “The verification panel on the project page”When the funder opens the project (status: submitted), the project’s detail page shows a verification panel.
| Visible text | Translation key |
|---|---|
| Panel heading | Projects.request-verification.project-verification-required |
| Body (mentions company + project name) | Projects.request-verification.project-verification-required-content |
| ”Verify” button | Projects.request-verification.verify |
| ”Reject” button | Projects.request-verification.reject |
If they choose Reject
Section titled “If they choose Reject”A modal opens asking for a reason.
| Visible text | Translation key |
|---|---|
| Modal title | Projects.request-verification.reject-modal.title |
| Reason field label | Projects.request-verification.reject-modal.reason-label |
| Reason placeholder | Projects.request-verification.reject-modal.reason-placeholder |
The reason field is optional and capped at 1000 characters.
After deciding
Section titled “After deciding”| Outcome | Translation key |
|---|---|
| Approved — heading | Projects.request-verification.project-approved-title |
| Approved — body | Projects.request-verification.project-approved-content |
| Approved — toast | Projects.request-verification.verify-success |
| Rejected — heading | Projects.request-verification.project-rejected-title |
| Rejected — body | Projects.request-verification.project-rejected-content |
| Rejected — toast | Projects.request-verification.reject-success |
If a funder opens a project that’s already been approved or rejected, the panel shows the relevant past-tense outcome instead of action buttons — preventing double-approvals.
What you can customise
Section titled “What you can customise”Translations
Section titled “Translations”All approve/reject UI text lives under Projects.request-verification.* in tep-configuration/translations/{locale}/main/projects.json. Override per client.
The outcome email back to the producer
Section titled “The outcome email back to the producer”The producer receives a project-verified email after the funder decides (the email is used for both approve and reject — it carries the outcome and any rejection reason). Override per client by providing {client}-project-verified.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 project-verified email template.
Need more detail?
Section titled “Need more detail?”For the status-check rendering, the toolbar variant, and the mutation, see Approving or rejecting a project (engineering).