> 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/release-updates/2026/july.md). # July #### **Update 24.07.2026 Release #3** ## More Control Over Responsibilities and Permissions {% @arcade/embed flowId="lA89SiR3lZYcuBpaZom9" url="" %} This release introduces new options for assigning responsibilities and controlling access within your organization. You can now assign Service Owners through organizational groups, delegate the management of selected Service Portfolio products, and decide whether employees automatically receive the Supervisor role when they are assigned as a supervisor. These features are available in customer environments, including managed and standalone customer environments. They are not available in supplier environments. ### Assign Service Owners through Groups Service ownership can now be assigned to an organizational group instead of a specific employee. This is useful for services that are managed by a department, team, or project group rather than one individual. Typical examples include shared devices, servers, location equipment, infrastructure services, or centrally managed workplace services. The assigned group is displayed under **Service owner** in the assignment details of the service instance.
Asset details showing the assigned Service Owner group under Assignment details. #### How Service Owner access works Assigning a group as Service Owner does not automatically grant additional access to every employee in that group. An employee receives Service Owner access only when both conditions are met: 1. The employee is a member of the assigned Service Owner group. 2. The employee has the **Service Business Owner** role. {% hint style="warning" %} The role must be assigned separately. It is not automatically granted when a group is selected as the Service Owner. {% endhint %} This separation allows organizations to define which team is responsible for a service without automatically giving every team member additional permissions. #### Viewing services as a Service Owner Employees who meet both requirements can see the relevant services in their Inventory, even when those services are not assigned directly to them as an employee.
\ Inventory view showing the services available to an authorized Service Owner. Screenshot 1 should remain close to Screenshot 2 in the article. The Inventory screenshot alone does not explain why the additional service is visible. The asset details provide the required Service Owner context. ### Define a Default Service Owner in the Service Portfolio A default Service Owner can also be configured directly on a product in the Service Portfolio. The product details now include a **Responsibilities** section. Under **Service owner**, you can select the group that should become responsible for future service instances created from that product. When the product is ordered and a new service instance is created, the configured Service Owner group is automatically transferred to the new instance. This avoids having to assign the Service Owner manually after every order.
\ Service Portfolio product with Management and Service Owner groups configured under Responsibilities. The two fields under Responsibilities serve different purposes: **Management** determines which organizational group may manage the product in the Service Portfolio. **Service owner** determines which group will be assigned as the Service Owner when a service instance is created from the product. These groups may be identical, but they do not have to be. ### Delegate Access to Selected Service Portfolio Products Previously, employees with Portfolio Manager access could manage the complete Service Portfolio. The new **Restricted portfolio manager** permission makes it possible to delegate access only to selected products. This allows departments or specialist teams to manage their own products without receiving access to the entire company portfolio. #### Configure the managing group Each product can now have a group assigned under **Responsibilities → Management**. This group defines which organizational unit is responsible for managing the product. For example, a monitor can be assigned to the **IT Procurement** group, while mobile phone products can be managed by a different team.
\ Responsibilities section showing the group assigned under Management. The same screenshot is relevant for both Service Owner configuration and restricted portfolio management. It does not need to be inserted twice. One screenshot can support both explanations when placed between the two sections. #### Grant the Restricted Portfolio Manager permission The employee must also receive the **Restricted portfolio manager** permission. The permission can be enabled in the employee’s permission settings.
\ Employee permissions with Restricted portfolio manager enabled. Access is provided only when both conditions are met: 1. The employee belongs to the group assigned under Management. 2. The employee has the Restricted portfolio manager permission. If either condition is missing, the employee cannot manage the corresponding product. #### Work within a restricted portfolio Employees with the **Restricted portfolio manager** permission receive a Service Portfolio view containing only the products assigned to their Management groups. They can view, create, and manage products within this scope without receiving access to products managed by other teams.
\ Removing the permission or changing the Management group removes the employee’s access. Products that were previously created or edited by the employee remain in the Service Portfolio. ### Delegate Fulfillment by Group Fulfillment responsibilities can now also be assigned to an organisational group directly in the Service Portfolio. Under **Responsibilities → Fulfillment**, you can define which group is responsible for processing orders related to the product. To receive access, an employee must meet both conditions: 1. The employee belongs to the assigned Fulfillment group. 2. The employee has the **Restricted fulfillment user** permission. When both conditions are met, the employee receives access to **Order processing** for the relevant products. They can work with the corresponding internal fulfillment orders and update their status during provisioning. Employees do not receive access to orders for products assigned to other Fulfillment groups.
### Control Automatic Supervisor Role Assignment Supervisor information and system permissions can now be managed separately. Previously, an employee automatically received the Supervisor role as soon as they were assigned as another employee’s supervisor. This also applies when supervisor assignments are imported or synchronized through HR Sync, as well as when they are entered manually. For some organizations, the supervisor relationship is required only as organizational information. It should not automatically grant access to employees, approvals, or services. #### Disable automatic role assignment A new setting is available under: **Settings → Roles and rights → Supervisor → Settings** The **Automatically assign this role** option determines whether the Supervisor role is automatically assigned when an employee is selected as someone’s supervisor.
\ Supervisor role settings with automatic role assignment enabled. When the setting is enabled, the existing behavior remains unchanged. Employees automatically receive the Supervisor role when they are assigned as a supervisor. When the setting is disabled, the supervisor relationship imported or synchronized through HR Sync is still stored in the employee profile, but the Supervisor role and its associated permissions are not assigned automatically. Automatic assignment remains enabled by default. Organizations that want to separate supervisor information from system permissions must disable the setting manually. ### Summary The new options provide more precise control over responsibilities and permissions: * Service ownership can be assigned to organisational groups. * Default Service Owners can be configured in the Service Portfolio. * Service Portfolio management can be restricted to products assigned to the employee’s Management groups. * Fulfillment access can be restricted to orders related to products assigned to the employee’s Fulfillment groups. * Supervisor assignments synchronized through HR Sync can be stored without automatically granting the Supervisor role. Together, these changes make it easier to delegate service ownership, portfolio management, and fulfillment across departments while retaining control over which employees receive additional system access. *** #### **Update 10.07.2026 Release #2** ## More Transparency in Orders: Requester Now Visible Orders often involve several people. One person submits the request, another approves it, and someone else may place the final order. Until now, the order view showed who placed the order and who the ordered service was assigned to, but not who originally requested it. With the new **Requester** column, this information is now retained and displayed directly in the order overview. ### Clearly distinguish between requester and purchaser For example, when an employee submits a product request through self service and a manager later places the order, both roles can now be identified correctly. The person who originally initiated the request is shown in the **Requester** column. This also applies when a manager or administrator creates a request on behalf of another person. As a result, it is easier to understand who initiated the original demand and who handled the order afterwards. ### Better traceability throughout the ordering process The additional information improves transparency and makes follow-up questions easier to resolve. Teams can now identify directly within the order: • who originally submitted the request\ • who placed the order\ • who the product or service was assigned to This keeps responsibilities clearly separated, even in more complex approval and ordering workflows. ### Available directly in the order overview
The new **Requester** column is available in the order view and displays the requesting person alongside the existing order information. There is no need to return to the original order request to find this information. The requester information is stored when the order is created and remains available throughout the ordering process. *** ## Customize Inventory Views with Expandable Table Columns Asset data is not the same for every organization. While one team may need quick access to serial numbers, another may work with CPU specifications, internal references, or other custom asset information.
With **Expandable Table Columns**, administrators can now add organization-specific information as dedicated columns in the inventory table. ### Display custom asset information directly in the inventory Additional information stored on an asset can now be displayed in its own inventory column. Instead of opening individual assets or reviewing combined metadata fields, users can see the relevant information directly in the table. Typical examples include: • Serial numbers\ • CPU specifications\ • Internal identifiers\ • Contract references\ • Organization-specific classifications This makes inventory views easier to scan and allows teams to focus on the information that matters for their workflows. ### Configure columns in the portal settings Administrators can configure expandable columns under: **Settings → Portal Settings → Expandable table columns** First, select the table that should be extended. The initial release supports the **Inventory** table. Then enter the name of the custom asset information that should be displayed and add it as a column. The column name is matched with the corresponding additional information stored on the assets. Where a matching value exists, it is displayed in the inventory table. ### Available throughout the tenant Once an administrator has configured a column, it becomes available to users across the tenant. The column is not automatically shown in every personal view. Individual users can decide whether they want to display it and include it in their saved table views. This keeps the configuration centrally managed while allowing users to adapt their inventory view to their own responsibilities. ### Included in inventory exports Expandable columns are also included in inventory exports. This allows teams to continue working with custom asset information in spreadsheet tools and use it for reporting, filtering, or further processing. ### Initial scope Expandable Table Columns are initially available for the inventory table and support custom information defined directly on assets. Filtering and grouping by these columns are not yet available within the inventory view itself. However, the values are already included in exported data and can be filtered there. Additional tables and capabilities may be added in future updates. *** ## Store Files Directly on Assets with Asset Attachments Asset records often require more than technical data and lifecycle information. Teams also need quick access to manuals, invoices, reports, images, and other asset-related files. With **Asset Attachments**, files can now be uploaded and stored directly within an asset’s detail view. ### Keep asset-related files where they belong Attachments are stored directly on the asset, making it easier to keep important documentation connected to the item it belongs to.
Typical examples include: • manuals\ • invoices and purchase documents\ • service or inspection reports\ • warranty documents\ • configuration files\ • images and supporting material This reduces the need to manage asset-related files in separate tools or folders. ### Upload, manage, and download files from the asset view Within the asset detail view, users can upload files directly to the **Attachments** section. Existing files remain linked to the asset and can be accessed again whenever needed. Attachments can also be managed after upload. Depending on permissions, users can download files, update their details, or remove them. ### Secure and tenant-specific access Uploaded files are not publicly accessible. Only users with access to the corresponding tenant and asset can view and download them. This ensures that internal or sensitive documentation remains protected within the platform. ### File size limit Each attachment can currently have a maximum file size of **20 MB**. ### Better documentation across the asset lifecycle By combining structured asset data with related files, teams get a more complete view of every item. Important documentation stays available throughout the full asset lifecycle, from procurement to daily operation and beyond. *** #### **Update 02.07.2026 Release #1** ## Category attributes now appear on existing inventory instances Inventory data requirements often change over time. A company may start by managing devices with basic information only and later decide that every device should also include a serial number, IMEI, email address or another internal reference. With this update, standard attributes added on category level are now also shown on existing inventory instances that belong to products from that category.
### What changed In Equipme, products can have attributes with predefined values. These are product specific attributes that can be transferred when a new service instance is created. Categories work differently. A category attribute defines a standard field for all products within that category. It does not contain a value yet, because the actual value belongs to the individual inventory instance. For example, a device category can define that every device should have a **Serial Number** field. The category only defines the field itself. The actual serial number is entered later on the individual device instance. Until now, category attributes were only applied when a new service instance was created. If a new standard attribute was added to the category later, existing inventory instances did not automatically show that new field. With this update, these new category attributes are now also displayed on existing matching inventory instances. ### Example A company manages multiple devices in the inventory. Later, the team decides that all devices should include a serial number. The admin adds **Serial Number** as a standard attribute on the device category. From that point on, existing inventory instances from this category will also show the **Serial Number** field in their attributes section. The field appears without a value first, because Equipme does not know the actual serial number of each individual device. The responsible user can then open the inventory instance and add the correct serial number directly on that item. ### What this improves This update makes it easier to extend inventory data requirements after services have already been created. Teams can define new standard fields on category level and see those fields appear on the relevant existing inventory instances. This helps users identify which information still needs to be maintained and keeps data structures more consistent across similar assets or services. It is especially useful when companies introduce new documentation requirements later, such as serial numbers, IMEI numbers, internal references or other service specific information. ### Important to know The new category attribute appears without a value. Equipme does not automatically generate, copy or fill the actual value. The value still needs to be maintained on the individual inventory instance. Empty attributes are visible on the inventory instance itself. In the inventory list, empty attributes are currently not shown in the attributes column. Attributes are displayed there once they contain a value. *** ## Import cost centers into Equipme Large cost center structures can be difficult to set up manually. This is especially true when a company already has a long list of cost centers, but does not manage all of them through HR sync. With the new cost center import, teams can bring this structure into Equipme faster and prepare cost centers before employees are assigned to them.
### What changed Until now, cost centers were either created manually or appeared through HR sync when synchronized employees already had a cost center assigned. That did not cover every setup. Some companies do not use HR sync for this data. Others need to prepare cost centers before employee data is connected. In those cases, creating a large number of cost centers manually was the only option. The new import solves this by allowing teams to upload cost center data directly in the company profile. ### What can be included in the import The import supports the core information needed for cost center setup: Cost center name or code, description, managers and billing address information. Managers and billing addresses can be included, but both are optional. Cost centers can also be imported without them and completed later. ### Manager validation Managers can be entered as comma separated values during the import. Equipme checks whether the listed managers exist in the company. If a manager cannot be found, the import shows an error and prevents the cost center from being imported with an invalid manager reference. This helps keep the imported data clean and avoids broken manager assignments. ### Linking billing addresses Billing addresses can also be linked during the import. Instead of entering the full billing address as free text, Equipme uses the existing Billing Address Profile Name. This avoids unreliable address matching, where small differences in spelling, formatting or spacing could lead to problems. If the billing address already exists in Equipme, the import can connect it to the cost center by using the exact profile name. The profile name must match exactly. If a space is missing or the name is written differently, Equipme cannot find the billing address profile and the import will show an error. ### What this improves The import reduces manual setup work for larger company structures. Teams can prepare cost center data outside Equipme and import it in one step instead of creating each cost center individually. This is useful during customer setup, larger rollouts or when cost center data is maintained outside the HR sync process. It also makes the process more controlled. Managers are validated against existing company users, and billing addresses are linked through existing profile names instead of free text address matching. ### Important to know Managers and billing addresses are optional. If managers are included, they must already exist in the company. If a billing address should be linked, the Billing Address Profile Name must match an existing profile exactly. Otherwise, Equipme cannot connect the billing address during the import. *** ## Move services directly from Inventory Moving services is now available directly from the Inventory. Users can select one or multiple services and move them to another employee or location from the inventory view. This makes service moves more accessible for operations teams that already work from the central inventory list. ### What changed Until now, moving services was possible from the Employee Services view under **Actions**, but the same action was not available directly in the Inventory. With this update, the move action is now also supported in the Inventory and follows the same logic across the relevant service views. After selecting the services, users can start the move action and choose whether the selected services should be moved to an employee or to a location. ### Choosing the target The move dialog separates the available targets into employees and locations. When moving services to an employee, users can select from the employee list. When moving services to a location, they can switch to the location view and choose the relevant location instead. This keeps the flow clear: first select the services, then choose where they should be moved. ### Availability check before moving Not every service can always be moved to every target. Some services may be blocked because of their current status or other move conditions. To make this clearer, Equipme now checks the selected services during the move flow. The dialog shows how many of the selected services can be moved to a specific employee or location. For example, if four services are selected, the availability column may show that only three out of four services can be moved to a certain target. Users can open the availability details to see which services can be moved and why specific services cannot be moved. ### Better feedback for partial moves The update also improves cases where only part of the selection can be moved. Before the target selection is shown, Equipme checks whether some of the selected services cannot be moved at all. If this happens, users see which services are blocked and can decide how to continue. They can either proceed with the remaining movable services or adjust their selection before starting the move again. This helps avoid unclear situations where a move simply fails without enough context. ### What this improves The new move flow makes service moves easier to manage from the Inventory. Teams no longer need to switch to the Employee Services view when they want to move services from the inventory list. They can start the action where they already work, select the relevant services and review possible restrictions before completing the move. The availability check also makes larger moves more predictable. Instead of only seeing that something does not work, users get more context about what can be moved, what cannot be moved and why. ### Important to know The move action supports moving services to employees or locations. Availability depends on the selected services, the selected target and the conditions that apply to the move. If a selected service cannot be moved, Equipme shows additional information so users can understand the restriction before completing the action. --- # 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, and the optional `goal` query parameter: ``` GET https://hub.equipme.io/release-updates/2026/july.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.