Structure your competency tree
Set up your competency tree so it still works when it holds hundreds of entries, not ten. This article helps you choose your categories and decide how deep to go, before you start adding competencies. These choices are hard to change later, so make them now.
Where to start
Agree the top level with your discipline leads before you create anything. HR keeps the tree tidy, but the people who run mechanical, electrical or safety work are the ones who know what belongs where.
Then build one category at a time instead of sketching all of them at once. Start with the competencies that stop someone from being sent to work, usually safety and medical certificates. Those are the ones your first gap report has to be right about. Trade qualifications and product competence can follow.
Build the tree before you bring in what people already hold. A bulk import does not create competencies for you. It matches each one by title against a competency that already exists, and you can only record something that sits at the bottom of a branch, never a category. Rows fail when the title is missing from the tree. See Import personnel in bulk.
One tree, one root
Every competency view in People uses this one tree. It has exactly one root. The root cannot be deleted or deactivated, and only its title and description can be changed.
Markular has no separate category item for you to create. A category is just a competency that has other competencies under it. The lowest level in each branch is what you record on a person.
Do not put competencies straight under the root. In the Competency Matrix, each column sits under its nearest parent. A competency placed straight under the root gets the root's own name as its heading, or Uncategorized if your root is still called ROOT. Neither heading tells anyone what the column is about.
When you select Add Competency, Parent Category is already set to the root. Change it to a category every time.
📷 Screenshot needed: the All Competencies screen showing the Competency Hierarchy panel with one root, a few categories, and competencies nested under them.
Use two levels below the root
In a deeper tree, the upper levels never appear in the matrix, and the matrix is the view most people use:
Competencies <- the root
└── Mechanical <- the category, this is what the matrix shows
└── Controlled bolting <- the competency you record on a person
If you add a third or fourth level, only the deepest category names the group in the matrix and in the Excel export. The levels above it still exist, but they never appear in the matrix or the export. Use three levels: root, category, competency. Go deeper only if you have a clear reason.
An empty category behaves like a competency. Until you add something under it, it appears in the matrix as its own column. Fill each category soon after you create it.
Organise by what the work needs, not by how it was earned
The most common mistake is to build the top level around document types:
Competencies
├── Certificates
├── Internal courses
├── External courses
└── Trade certificates
This splits one subject across several branches. It also repeats work the tree already does for you. Every competency is marked either Skill or Certificate. The Type filter on All Competencies already lets you show just one of them.
Build the top level around subjects instead:
Competencies
├── HSE and working environment
├── Mechanical
├── Hydraulics, pneumatics and pressure
├── Electrical, instrumentation and automation
└── Lifting, rigging and material handling
A starter set of categories
Use this as a starting point and delete what does not apply. Most organisations end up with six to ten categories. The matrix colours the category headings, and it uses six colours before starting again from the first. From the seventh category onwards, two categories can share a colour. That is not a problem, but a very long list gets harder to scan.
- HSE and working environment
- Safety and emergency response
- Mechanical
- Hydraulics, pneumatics and pressure
- Electrical, instrumentation and automation
- Lifting, rigging and material handling
- Inspection, testing and quality
- Equipment and product competence
- Operations and work processes
- Leadership and supervision
Add your own categories where your work needs them. Do not put numbers in the category titles. The title text appears in every matrix heading and every export. You set the order by dragging rows in the tree instead, and dragging works when the tree is set to Manual rather than Alphabetical.
One competency, one place
Create each competency once, in one place. A trade certificate for remote operations may involve electrical, hydraulics, mechanical and subsea work, but it is still one competency and belongs in one branch.
When a competency could fit in several places, ask these in order:
- What can the person do once they hold it?
- What is the main subject: a trade, an operation, a product, a work method, or a responsibility?
- Which subject area would own it, meaning who would keep it up to date?
- Where would a manager look for it first?
If the answers disagree, let the first two decide. Place a competency by the end result it represents, not by the subjects that go into earning it.
Avoid duplicates for a practical reason. The person's record, the matrix column, and every requirement all use the same single entry. If you create the same subject twice, the history splits between the two copies, and your gaps look smaller than they really are.
Name a competency the way your people would say it out loud. The matrix shows competency names sideways in narrow columns, so long names are hard to read.
Put the detail on the competency, not in the tree
Each competency carries its own settings, so you rarely need extra branches to express a distinction:
| Setting | What it does |
|---|---|
| Certificate | Marks the entry as a certificate rather than a skill. Drives the type filter and the Certificate Expiry view |
| Has proficiency levels and Number of Levels | Records a level from two to six instead of a simple yes or no |
| Requires documentation | The record only counts once a file is attached to it |
| Active | Retires an entry without deleting it |
Three things are easy to miss:
Levels are numbers, not names. The tree stores how many levels exist, not what they mean. If you use levels, write the meaning of each one into the competency's description, so "level 3 of 5" means the same thing to everyone reading it. Levels also change what gets stored. A competency with levels can keep one entry for each level the person reaches, so you can see their progress over time. A certificate or a plain skill keeps one entry per person.
Turning on documentation has real effects. With Requires documentation on, a record without an attached file is treated as incomplete. It shows up in Missing Documentation, and if your organisation uses Planner, that person does not meet the requirement when they are considered for work that needs it. Use it where you genuinely need the evidence on file.
Validity is set per person, not per competency. The tree has no renewal interval. Start and end dates belong to each person's record, which means a certificate's expiry is entered when it is recorded against someone.
Certificate Expiry and its reminders both work from the end date on the person's record. If that date is left empty, the certificate stays out of the expiry view and out of the reminders, and it will look valid indefinitely. Make entering the end date part of your routine when you record a certificate.
Do not rebuild the org chart
Departments and locations change far more often than subjects do. A tree shaped like today's org chart needs rebuilding after every reorganisation, while Mechanical and Quality stay the same for years.
The same applies to splitting the tree by where the work happens. Branches such as Onshore and Offshore, or one branch per site, duplicate every subject underneath them. Departments and locations are already available as filters in the matrix and the reports, so you do not need them in the tree.
Where a requirement really is specific to a place or a customer, express it as a requirement rather than as a branch:
- In People, group requirements into a job capsule, which is a named set of required competencies. Attach it to the positions that share those requirements. This is what the gap analysis measures people against.
- If your organisation uses Planner, requirements can also follow the job role, the installation, the job type, or the customer, and a person considered for work is measured against all of those together.
Because both approaches use this one tree, a competency only needs to exist once for either to use it.
Retire a competency instead of deleting it
Once people hold a competency, deactivate it instead of deleting it. Deactivating keeps the entry and its history, and removes it from the active lists.
You can only delete a competency when all three of these are true: nobody holds it, it has no competencies under it, and it is not the root.
A branch cannot be deactivated while it still has active competencies under it, so retire those first. The root itself can never be deactivated.
Turn on Show inactive to see what you have retired.
What you can do
- Read how requirements, holdings, and gaps fit together before you design the tree, so you know what your structure will be used for.
- Open the competency matrix to check that your category headings read well across a whole team.
- Read require and track competency documentation if you turn on Requires documentation.