> For the complete documentation index, see [llms.txt](https://hub.equipme.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.equipme.io/equipme/settings-1/roles-and-rights/ordering-in-equipme-roles-scope-and-responsibilities.md).
# Ordering in equipme: roles, scope and responsibilities
Ordering in equipme is driven by roles rather than by individual switches or a central ordering button. A user can only request, place or approve orders if the role they hold includes buying capabilities. This capability does not exist as a single toggle that someone turns on or off. It sits within the role itself, and it becomes active the moment the role is assigned to a user.
This approach might seem indirect at first, especially if someone comes from systems where ordering is managed by one person or one department. equipme intentionally distributes responsibility, because organisations themselves distribute responsibility. A retail chain may want store managers to order independently. An engineering team may want team leaders to request equipment for their staff. A supervisor may oversee multiple departments and handle escalation. A system admin may simply need the ability to resolve urgent issues.
equipme lets all of these realities coexist without collapsing them into one central bottleneck.
***
### **Roles and their capabilities**
Several roles inside equipme are designed to initiate procurement actions. They differ not only in what they can do, but also in where they are meant to operate.
A **Location Manager, Buyer** is responsible for ordering at a specific site. When someone holds this role, they can place orders for the location they are assigned to. The reason this role exists is simple: many organisations want procurement decisions to happen close to the environment where work is done. It avoids delays, gives people autonomy, and reflects actual operational realities.
A **Team Manager** has a different perspective. Rather than representing a building or geographic location, they represent a group of people. Their responsibility is not “keep this site supplied”, but “make sure everyone in my team has what they need to work”. Team Managers can place orders for employees in their group, and depending on configuration, they may also approve requests. Unlike Location Managers, their authority doesn’t come from where work happens, but from who they manage.
A **Supervisor** works at a broader level. They may operate across departments or locations, place orders that affect multiple groups, or approve requests made by others. Many organisations use supervisors as a safeguard, someone who sees the bigger picture and ensures choices don’t conflict with budgets, standards or policies.
And then there’s the **Admin**. Admins are not primarily defined by the responsibility to request things for employees, but they have the technical ability to place orders when necessary. Their role reflects a different organisational truth: sometimes someone simply has to fix things when others can’t. It is not unusual for an admin to resolve a blocked process, submit a missing order, or handle onboarding tasks that slipped through the cracks.
The key idea here is: roles do not exist purely for workflow symmetry. They exist because the organisation has different kinds of responsibility, and equipme maps those responsibilities into practical capabilities.
***
### **Permissions shape the experience, but they do not create buying capabilities**
When looking at role configuration in equipme, it is easy to assume that ordering must be enabled through a checkbox. The interface shows settings for things like viewing prices, accessing the marketplace, capturing inventory, or seeing employees. These are genuine permissions. They influence what a user can view, what they interact with, and how much detail they have access to.
But they do not grant or remove the basic ability to place orders.
This often confuses new administrators, because the UI gives them a list of toggles and they expect to find one labelled “can place orders”. If it existed, it would make the system feel simpler. And also, less realistic.
Buying power in organisations is rarely a small optional feature someone ticks. It is a responsibility tied to position, authority, accountability and context. equipme follows that principle: if a role is designed to commit spending decisions, it will be able to do so. If not, no combination of visibility features will make it happen.
A Team Manager may see employees but not prices.\
A Location Manager may see costs but not inventory operations.\
An Admin may see everything, yet only use that ability occasionally.
Permissions refine what working in a role feels like.\
Roles define what working in a role can achieve.
***
### **Scope matters**
Ordering in equipme is never universal or free-floating. Someone cannot simply browse all resources and start ordering without limitation. Ordering is always tied to the context a role operates in.
A Location Manager orders for their location. They cannot order for another site unless they are assigned there as well.
A Team Manager orders for their team. They cannot request items for employees outside their group.
A Supervisor operates across multiple areas, but still within boundaries defined by configuration.
An Admin can step in anywhere, but doing so is an exception, not a habitual workflow.
This mirrors organisational structure: people are responsible for the domains they lead, not for everything that exists.
***
### **Approvals, workflows and organisational preferences**
Ordering is only one part of procurement. The second part is approval. Approval exists to protect commitments, control costs, and prevent one person from unilaterally committing spending that affects others.
When an order is submitted, equipme may route it through an approval step, depending on the workflow configuration. Some organisations enable automatic approval for self service, because the cost structure is predictable. Others use multi-party approval, because decisions are risk-bearing.
Workflows define how the process unfolds.\
Roles define who can participate in it.
Combining both gives organisations flexibility: they can let people work autonomously while still protecting themselves from poor decisions.
***
### **Visibility is not buying power**
Many roles can see marketplace items, prices, costs, inventory or employees, but still cannot place orders. This is not an accident. It is intentional.
equipme separates **awareness** from **authority**, because showing someone the cost of something does not automatically grant them the right to commit that cost.
Understanding this distinction helps decode the platform: if a user can see a lot but do little, they don’t lack features. They lack responsibility.
***
### **A model built around reality, not software limits**
The design of ordering in equipme tries not to reflect what software is easiest to build, but what organisational behaviour is easiest to support.
Organisations differ dramatically in how they handle procurement. Some decentralise spending entirely. Some centralise everything. Some let teams order autonomously but require approval for expensive items.
equipme doesn’t force a particular philosophy. It enables several.\
By anchoring ordering in roles and mapping those roles to real-world contexts, the system makes procurement a structural, not a technical, question.
***
### **In short**
Ordering in equipme is role-based.\
Buying capability comes from the role, not from a single permission toggle.
Several roles can place orders, including:
* Location Manager, Buyer
* Team Manager
* Supervisor
* Admin
Each role operates in a specific context, with its own scope and responsibilities.\
Permissions refine what users can view or modify, but they do not grant or remove the fundamental ability to order.\
Approval, when required, is governed by workflow configuration, not by the role alone.
The goal is not to standardise decision-making, but to support the different ways organisations actually work.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://hub.equipme.io/equipme/settings-1/roles-and-rights/ordering-in-equipme-roles-scope-and-responsibilities.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.