Roles and access
Two questions get asked constantly and have different answers: what is my job on this project, and what am I allowed to do in the software. In KI those are separate systems, and they do not line up neatly.
Roles and permissions are two different things
Section titled “Roles and permissions are two different things”A project role says what you do. Being the site lead on a project puts your name on it, tells people who to call, and routes work to you.
Permissions say what you may open. They are set on your user account, once, by an administrator, and they apply everywhere in the software rather than to one project.
Being assigned to a project therefore does not grant you anything, and holding a permission does not put you on a project. If you can see a screen but not the job you need, that is a project assignment problem. If you cannot see the screen at all, that is a permissions problem, and a different person fixes it.
The four project roles
Section titled “The four project roles”Projects carry four roles, assigned per project and shown to the client in the Client Portal.
| Role | What they do |
|---|---|
| Project Planner | Owns the money: pricing, procurement, margin, change orders |
| Design Manager | Owns the design through its phases |
| Site Manager | Runs the work on site |
| Interior Designer | Produces the design |
Two more roles exist outside the project team. A Client is the homeowner, who signs in to the Client Portal to review and approve. A Vendor is a supplier or trade, who signs in to the Vendor Portal to receive purchase orders. Both are the same people you already work with; the role is only what the software calls them when they log in.
The list is fixed. You pick from it rather than inventing a role, which is why somebody whose job does not match one of the four still has to be recorded as whichever comes closest.
Two naming traps. Some Admin Portal and Client Portal screens still say Planning Manager where they mean Project Planner — a known defect, not a second role. And the Client is called the owner on several screens, which is construction convention for the party paying for the work. See the glossary.
What your account may open
Section titled “What your account may open”The four roles above decide who does the work. What you can open is decided separately, by the role on your user account, and the two do not line up neatly.
Account roles
Section titled “Account roles”In the Admin Portal, your account role decides what you can open. An administrator assigns it, once, and it applies to every project. There are six:
| Account role | What it opens |
|---|---|
| Admin | Everything |
| Accounting | Accounting work across every project |
| Accounting Support | Accounting work across every project, without employee records |
| Division Leadership | The projects in your own division |
| Project Management | The projects you are on or that were shared with you; purchase orders and their change orders; approving vendor invoices. Employee records and financial reports are not included |
| Project Support | The projects you are on or that were shared with you, with Cost Control, Contacts and Forms hidden. Financials shows purchase orders only, design documents can be read but not uploaded or removed, and the milestone report is view-only |
Two things follow from that:
- A screen your role does not include is not in your menu. Asking for it is a conversation about your role, not a bug report.
- Projects you are not on are not in your list. Share project access, below, is the way to open a single project without changing anyone’s role.
Legacy KI still works the old way. Its screens are governed by roughly ninety individual permissions set Full, Read or None on each account, and three things follow from that:
- Every permission is set on one account at a time. Nothing groups them, so two people doing the same job can end up with different access, and a new starter is set up by copying somebody.
- Seeing a budget and seeing what a job actually cost are separate. Can View Actuals is granted on its own.
- Approvals are recorded rather than enforced. The software logs who approved something and draws buttons based on your permissions, but the routine that advances a document does not itself check that you were eligible.
Sharing a single project
Section titled “Sharing a single project”One piece of that machinery is already usable: Share project access, on the project screen, grants one employee or client contact access to that project without putting them on the project team.
The two are often confused, so the distinction is worth stating. Putting someone on the project team says they hold a role on the job, and the client sees them listed for it. Sharing grants access and nothing else, which is what the estimator looking up last year’s job or the accountant covering someone’s leave actually needs.
Which portal you sign in to
Section titled “Which portal you sign in to”Access is also decided by the address, since each interface has its own. Employees use the Admin Portal, or Legacy KI for the modules that still live there. Clients and vendors use the portal built for them and see only their own project or their own purchase orders. The list of addresses is on The software.
How access is put together
Section titled “How access is put together”Legacy KI, which is the admin portal on this instance, has no list of roles to pick from. Access is built up per person out of roughly ninety individual permissions, each set to Full, Read or None.
The job titles everyone uses — Estimator, Superintendent, Foreman, Project Manager, Accountant, AP (accounts payable) Clerk, AP Approver, Purchasing, Cost Engineer, Contracts and Compliance — are real descriptions of real work, but the software does not know them. It knows the ninety switches somebody set on your account.
That has consequences worth knowing before you ask for access:
- There is no “make me a Foreman” button. Someone compares your account to a colleague’s and matches the switches.
- Two people with the same job title can have different access, because their accounts were set up separately, at different times.
- Seeing a budget and seeing what a job actually cost are separate permissions. Can View Actuals is granted on its own. Being trusted with the budget does not imply it.
- Approvals are recorded rather than enforced. The software logs who approved something and draws buttons based on your permissions, but the routine that advances a document does not itself check that you were eligible.
Whether this instance eventually gets a defined set of roles is an open decision. It sits behind building out the people model, covering subcontractors, owners and engineers with access granted per individual, which project controls flagged as the thing to build first.
Which portal you sign in to
Section titled “Which portal you sign in to”Everything runs in Legacy KI on this instance, at its own address; the client and vendor portals are not set up here. The list of addresses is on The software.
Signing in to one interface does not sign you in to another, and an account on one company’s instance is not an account on the other’s. Story and Bristlecone keep separate user lists.
Who to ask
Section titled “Who to ask”Permission changes go to whoever administers Legacy KI for your company, not to the person who assigned you to the project. Project assignments are changed on the project itself by the team running it.
The feature matrix compares the two companies side by side, which is the one place here that deliberately shows both.