Every construction business runs a mix of everyday tenders and a handful that need to stay tightly controlled; whether that's because they sit with a specific regional team, or because they carry an NDA or security clearance. ConQuest is built around that reality: every project can be locked down to exactly the people who should see it, using the same straightforward mechanism throughout.
Creating a tender
Any authenticated user with access to the Projects Register can create a new tender. There isn't a separate approval step or role requirement standing in the way of getting a new project started; teams can move as fast as they need to when a new opportunity comes in.
If your organisation wants to reserve project creation for specific roles, that's a configuration worth discussing with us directly; it's not something that's restricted out of the box today.
Per-tender security
Every tender in ConQuest carries its own access settings. Rather than being an all-or-nothing system, each user can be given one of three levels of access to a given project:
Access level | What the user can do |
No Access | The project doesn't appear in their list at all. It's as if the tender doesn't exist for them. |
Read Only | They can open and view the tender, but can't change anything in it. |
Full Access | They can view and edit the tender freely. |
This is enforced at the project level, which means a tender that's restricted simply won't appear in the list for anyone who hasn't been given access — there's nothing for an unauthorised user to stumble across.
Assigning access by team, not just one person at a time
Managing access one user at a time doesn't scale once you have real teams involved. ConQuest supports User Groups — you define a group once (for example, an estimating team, a regional office, or a project delivery team) and assign that entire group an access level on a tender in a single step.
If someone belongs to more than one group, they simply get the highest level of access granted by any group they're part of — so overlapping memberships never accidentally reduce someone's access.
Business unit-level visibility
For organisations structured around distinct business units; each with its own estimators and surveyors, the recommended approach is to create one Group per business unit and assign that group to every tender belonging to it. In practice, this gives administrators a single, team-level switch to control visibility, rather than managing dozens of individual users.
ConQuest also has a separate Sector/Subsector field used for dashboard reporting and filtering. It's a useful way to organise how tenders are displayed, but it's worth being clear that it's a reporting label rather than a security control — the Groups mechanism above is what actually governs who can see what.
NDA and confidential tenders
Tenders that carry an NDA, security clearance, or other sensitivity requirement don't need a special flag or separate workflow. Because access to every project is closed by default and only opened to the people explicitly listed, restricting a sensitive tender to a small, named group of cleared individuals uses exactly the same mechanism described above; just applied narrowly, on that one project.
In other words: the everyday access control and the NDA-grade access control are the same feature, used at different scopes. There's nothing extra to configure, and nothing separate to maintain.
The 'master' profile — a default worth knowing about
📌Note: Users on the 'master' profile automatically have full access to every project, including ones that are otherwise restricted or locked. This exists so that administrators can never accidentally lock themselves out of the system, and it's worth factoring into who is granted master rights within your organisation.
Project locking
Separately from who can see or edit a tender, ConQuest also allows any project to be locked entirely, preventing any further changes until it's explicitly unlocked. This is commonly used once a tender has been finalised, to freeze its state regardless of who otherwise holds edit access.
By default, only master-profile users can lock or unlock a project, though this permission can be extended to other user profiles if that better fits your team's workflow.
