Glossary

Ed Controls is a construction-site quality and snagging tool. The words construction managers, KAM coordinators, and subcontractors use on site do not always match the database table and column names in this schema. This page maps the product-language terms a stakeholder is likely to say or write to the database-language terms you actually query.

If you are reading a Slack message, a HubSpot ticket, or a customer support thread and a term does not match what you see in the schema, look it up here first.

Tickets

Product term	Database term	Description
Snag	tickets	The dominant term in EdControls marketing and on construction sites. A snag is a defect, a missing finish, or any item on a punch list that someone needs to fix.
Defect	tickets	Used interchangeably with "snag" in the EdControls marketing copy ("snagging, defect management and quality control").
Issue	tickets	Generic synonym used in customer-facing materials and integrations.
Action point	tickets	The pricing page describes the ticket module as the "on-site action points" module.
Task	tickets	App-store and mobile-UI synonym ("tasks, notes, drawings and quality checks").
Label	tickets_tags	The product UI calls a categorization tag a "label". The database table is tickets_tags.
Progress label	tickets_progress_labels	Free-text sub-status (e.g. "To Review", "Approved", "Ready for review") layered on top of the closed status enum.
Sub-status	tickets_progress_labels	Sometimes used in the EdControls blog as a synonym for "progress label".
Custom field	tickets_custom_fields	Per-project bespoke fields added to tickets. The product UI uses "custom field" verbatim.

Audits

Product term	Database term	Description
Audit	audits	The primary product term, matching the database. An audit is one execution of a checklist on a project.
Inspection	audits	Used interchangeably with "audit" in EdControls' own user manual ("Title of the audit/inspection/checklist").
Checklist	audits	The third synonym in EdControls' user manual. Common in Dutch sales conversations.
Quality check	audits	App-store and mobile-UI synonym ("tasks, notes, drawings and quality checks").
PVO (Proces Verbaal van Oplevering)	audits	Dutch handover-document term. PVO documents are stored as audits in EdControls (used by Heijmans/BTB and other Dutch contractors via the Salesforce/Boomi connector).

Audit templates

Product term	Database term	Description
Audit template	audittemplates	The primary product term, matching the database. A reusable blueprint of categories and questions.
Form	audittemplates	Internal product description: "audit templates are structured forms containing categories with questions".
Inspection template	audittemplates	Follows from the audit/inspection synonym above.
Template group	template_groups	A folder that organizes related audit templates. The UI calls it "template group" verbatim.

Maps

The single biggest naming gap between the product and the database: the product UI consistently uses "drawing" while the database uses "map". The Library tab is where users browse drawings, and the iOS changelog acknowledges the underlying entity by saying "the Library list is updated to display a combined view of Map and File".

Product term	Database term	Description
Drawing	maps	The dominant UI term. The Library tab, the support category ("Drawings & files"), and the marketing copy ("from the first drawing to final handover") all use this.
Floor plan	maps	A type of drawing — the most common concrete example a user will mention.
Site plan	maps	Another concrete drawing example. The schema's maps.name field carries titles like "Ground floor plan" or "Building A — Level 2".
Blueprint	maps	The marketing tickets page says "position the ticket on the construction blueprint" — the same entity as a drawing/map.
Drawing group	map_groups	A folder of drawings (e.g. "Building A"). The UI calls it "drawing group"; the database calls it map_groups.
Library	maps + files	The UI tab where drawings live. Files (non-drawing documents) are not in this schema — only the drawing rows are.

Projects, contracts, users

These three domains use the same words in the product and the database. They are listed here so a reader who is checking can be sure no alias exists.

Product term	Database term	Description
Project	projects	One construction project. Same name in the UI and the database.
Contract	contracts	The commercial agreement under which projects sit. Same name in the UI and the database.
User	users	A person who has logged into EdControls. Same name in the UI and the database.

RASCI roles

EdControls is built on a RASCI permission model. The product UI uses the role names verbatim, so the values you see in audit_roles.role, tickets_roles.role, project_participants.role, and the responsible columns on audits and tickets are exactly the role names a stakeholder will say.

Product term	Database term	Description
Administrator	(no role row)	Contract-level full-control role. Not assigned at the project, audit, or ticket level. Not represented as a row in any role table.
Manager	(no role row)	Contract-level dashboard-only role. Not represented as a row in any role table.
Accountable	project_participants.role = 'accountable'	The single owner of a project. One per project. Stored on project_participants.
Support	project_participants.role = 'support'	Project-level role with near-Accountable rights. Stored on project_participants.
Responsible	audits.responsible, tickets.responsible	The person who must complete the audit or ticket. Stored as an email column directly on the entity, not as a separate role row.
Consulted	project_participants.role = 'consulted'	Project-level view-and-comment role. Stored on project_participants.
Informed	project_participants.role = 'informed', audit_roles.role = 'informed', tickets_roles.role = 'informed'	View-only role. Can be set at the project, audit, or ticket level.
Reporter	(no role row)	Light-user role granted at the drawing level for ticket creation. The reporter relationship is enforced at the application layer; it does not appear as a row in the role tables in this schema.

Notes on the research

Two terms surfaced repeatedly during the research that did not make it into the table because they are workflow concepts rather than database entities:

• Snagging — the verb form of "snag". The act of walking a site and creating tickets. There is no snagging table; it is just the activity of inserting rows into tickets.
• Oplevering — Dutch for "handover" or "delivery". The deadline by which all open snags on a project must be closed. There is no oplevering column; the relevant data is on tickets.dueDate and audits.dueDate.

If you encounter another product term not listed above, raise it with the docs maintainers — most genuinely missing aliases are easier to add as a row in this table than to debug from a query later.