Key Concepts
Understanding a few terms will make everything else in Fundament much clearer.
Organization
The organization is the top-level entity in Fundament. Everything (forms, applications, team members, tags, email templates, automations) belongs to an organization and is fully isolated from other organizations. A team member always works inside a single organization. Who in the organization can see and do what is governed by roles and, optionally, user groups.
Portal
The portal is the organization’s public-facing website within Fundament. Applicants visit it to browse available forms and submit their applications. They also keep using the portal after submission: to check the application status, continue working on a saved draft, make and resubmit revisions the team has requested, and fill in additional form parts once the team unlocks them. Which fields applicants encounter in a form is documented in the field reference; how to set up the portal’s texts, colors, languages, and visibility is covered in Configuring the Portal. Each organization has its own portal with its own URL.
Workspace
The workspace is the team’s side of Fundament: the place where applications are reviewed, forms and automations are managed, and the organization is administered. Applicants never see it.
Form
A form defines the questions applicants are asked. Multiple forms can be active at the same time, for example one for each open funding round. A form can have multiple form parts, so information can be collected in stages. A form is built from different field types (text, number, choice, file, etc.) with validation rules attached to each field; the details are covered in the Forms chapter.
Application
When an applicant submits a form, an application is created. The application contains everything the applicant filled in, including uploaded files, together with metadata such as the submission date, application status, tags, internal comments from the team, and a complete history. Applications are where the team does most of its work; their full lifecycle, from submission to decision, is described in the Applications chapter.
Revision
Every time an application is changed, either by the applicant or by a team member editing the content, a new revision is created. This gives the team a complete, permanent history of every version of the application; nothing is ever overwritten. When the team needs a correction, it can request a revision. Note that the applicant is not notified automatically; that requires an automation. See Requesting Changes for the full picture.
Application Status
Every application carries two kinds of application status: a submission status that reflects what the applicant has done (Submitted, Revision Requested, Revised), and a custom application status that the team defines per form, for example “Under Review”, “Shortlisted”, “Approved”, or “Rejected”. Application status changes can be made manually or driven by automations, and a custom application status can optionally have an application status checklist attached to it. Details: Application Lifecycle.
Profile
A profile is a team member account within the organization. Each person who works on applications has their own profile with a role (Owner, Member, or User) that controls what they can see and do. Profiles can additionally be organized into user groups, for example “Jury 2025” or “Office”, to target polls at specific groups of people.
Applicant
An applicant is someone who submits an application through the portal. They have a separate, limited account: they sign in with a login link or a 6-digit code sent by email, no password, and only ever see their own applications and drafts (plus applications they have been invited to as a co-author). Applicants never see internal comments, votes, or any other application; the team’s only direct channel to them is through emails and revision requests.