Contest or call for papers

Blueprint for a contest or call for papers: apply, evaluate, notify outcomes, and let applicants track status.

Goals

• Public application form
• Staff evaluation area with scores
• Automated acceptance / rejection / waiting-list e-mails
• Applicant portal to see status and upload extras

Data model

Object	Key fields
Edition (optional)	name, year, open_from, open_until — or use a global object for a single campaign
Submission	title, abstract (Long Text), applicant_name, applicant_email, password (if applicants log in on the same object), status (Submitted / Under review / Accepted / Rejected / Waiting list), score (Number or Rating), file (File)
Evaluation (optional)	submission (Reference), reviewer (Reference → Operator), score, comments
Operator	staff login + roles (Reviewer, Admin)

If applicants should log in, either put password on Submission (one submission per login) or split Applicant (auth) and Submission (Reference → Applicant).

Portals

Portal	Login	Contents
Apply	None (or Applicant)	Form + rules text
Review	Operator	Submissions grid, detail, evaluation form
My submission	Applicant / Submission	Status detail, optional extra-file form when status allows

Key automations

• On submit: set status = Submitted, e-mail receipt
• Reviewer form: write score; Admin batch sets final status
• On final status: e-mail templates for Accepted / Rejected / Waiting list (E-mail tasks)
• Display rules: show upload fields only while status is Submitted or Waiting list

Evaluation tips

• Keep raw reviewer Evaluation rows separate from the final status on Submission so audits stay clear
• Use grid batch tasks only for admins (menu/visibility by role)
• Snapshot before mass notification sends

Build order

1. Submission object + public form
2. Review backoffice + scoring
3. Applicant status portal
4. Outcome e-mails
5. Optional Edition/global settings for open/close dates