Project settings
Almost everything in Builddar can be tailored per project. This page is the map: what you can change, who can change it, and where each setting lives.
Required role: Project Manager (or Organization Admin) for nearly all of it. A few items are Organization Admin only, and they're marked below.
How customization works
Builddar customizes on three layers. Knowing which layer a setting sits on tells you what happens when you change it.
1. Organization defaults — the template
Trades, zone types, and issue title suggestions are curated once at the organization level. They're a template: a new project gets its own copy of them at creation.
Editing an organization trade never changes an existing project. That project already owns its copy. This is deliberate — the same trade is lot 01 on one project and lot 03 on another, and a rename shouldn't ripple across live contracts.
See Configure shared catalogs.
2. Project settings — your copy
Inside a project, you edit that project's own copy. Nothing you do here affects your organization's defaults or any other project.
Some catalogs are shared live instead of copied: disciplines, company types, and the typology/orientation lists. Editing one of those changes it everywhere immediately. The table in Configure shared catalogs says which is which.
3. Personal preferences — yours alone
Notification settings and your profile are yours, across every project.
Where a project rule and a personal preference disagree, the project wins — see Project notification rules.
What you can customize
Project identity and details
Name, description, project type, start and end dates, and the site address. Edit these from the project's settings at any point in its life.
The address and dates appear on report covers and generated documents, so keep them accurate even if nothing in the app depends on them.
The way issues are logged
| Setting | What it controls | Where |
|---|---|---|
| Issue form | Which fields are required when logging an issue, and the default due-date windows | Create an issue |
| Workflow | The statuses an issue moves through and who can move it | Customize the issue workflow |
| Phases | The stages you group issues by | Phases |
| Trades | The project's work packages (lots) and their lot numbers | Trades and title suggestions |
| Title suggestions | The ready-made issue titles offered per trade | Trades and title suggestions |
The custom issue form and the custom workflow each depend on your plan.
The way the project is structured
| Setting | What it controls | Where |
|---|---|---|
| Zone types | The levels your zone tree is built from, and which type is a unit | Build the zone hierarchy |
| Lifecycle states | The labels, colors, and visibility of unit lifecycle states | Track the unit lifecycle |
| Companies | The contractors and firms on the project, and their trades | Manage companies |
| Members and roles | Who's on the project and what they can do | Manage project members |
What the project produces
| Setting | What it controls | Where |
|---|---|---|
| Report templates | Saved report configurations — filters, fields, grouping, cover page | Report templates |
| Scheduled reports | Reports generated and emailed automatically | Scheduled reports |
| Checklist templates | The reusable inspections your team runs | Create a checklist template |
| Info fields | Custom label/value pairs printed in document headers | Project info fields |
Who gets told what
| Setting | What it controls | Where |
|---|---|---|
| Notification rules | Which categories are Off, Optional, or Required for everyone on the project | Project notification rules |
| Escalation rules | Automatic due-date digests emailed to contractors | Escalation rules |
Access and privacy
| Setting | What it controls | Where |
|---|---|---|
| Zone access | Which zones a company, role, or person can see | Share zones |
| Document access | Which folders and documents are private, and who they're shared with | Share documents |
Capacity and lifecycle — Organization Admin
| Setting | What it controls | Where |
|---|---|---|
| Drawing quota | How many drawings the project can hold (per-project billing) | Upload drawings |
| Lifecycle actions | Activate, complete, archive, and their reverses | Project lifecycle |
Copy settings from an existing project
The fastest way to configure a project is to not configure it. When you create a project, you can copy settings from an existing one.
You choose individually which of these to copy:
| Setting | What comes across |
|---|---|
| Workflow | Statuses and transitions |
| Issue form configuration | Field requirements and due-date defaults |
| Phases | The detection phases |
| Escalation rules | The active due-date rules |
| Document folders | The folder structure — no files |
| Document tags | The tag definitions |
| Checklist templates | Templates with their sections and items |
Only the settings your plan enables are offered. Checklist templates don't appear unless checklists are enabled for your organization; document folders and tags need document management.
Build one project properly and treat it as your house standard. Every project after it starts from that instead of from Builddar's defaults.
Which features you have
A project's settings show which features are enabled for it — the read-only result of your organization's plan. If a setting described here doesn't appear in your product, check this first: it's almost always a plan gate rather than a permission problem.
What can't be customized
- Status types. You can rename and recolor statuses, but the five underlying types (Open, In Progress, Completed, Validated, Rejected) are fixed, and only In Progress statuses can be added. See Workflow overview.
- Required issue fields. Title, zone, detected-on date, and due date are always required and can't be turned off.
- Lifecycle state keys. Their labels are yours; the underlying keys are fixed so reporting works across projects.
- Project invitations. They always send.