Activate and roll out the optional Asset Management module
Platform administrator for tenant activation; tenant administrators and asset managers for setup and validation.
Asset Management is an optional module activated independently for each tenant. It supports equipment custody, stock and lifecycle work in both ITSM Lite and CSM Full. A complete CMDB is not a prerequisite.
Before you start
Choose an accountable asset manager, a small initial equipment scope and the people who will maintain assignments, stockrooms and lifecycle evidence. Agree asset-tag conventions, categories, models, physical locations and the meaning of your statuses before importing a large inventory.
Module activation, operating view and user permissions are separate controls. Giving someone the asset_mgr role does not enable a disabled module. CSM Full alone does not enable Asset Management either.
Steps
- Ask the platform administrator to enable Asset Management for the intended tenant through the module registry. Confirm the target tenant rather than assuming activation applies to every organisation.
- Assign the asset_mgr role to the people responsible for register administration. Reserve administrator access for settings that require it, including lifecycle and operational status configuration.
- Review seeded statuses and create the categories, models and stockrooms needed for the pilot. Default asset statuses are seeded for new tenants and on first activation for an existing tenant; existing lists are not intended to be overwritten.
- Register a few representative assets or preview a small CSV import. Resolve duplicate tags, incorrect reference values and unclear ownership before committing a larger batch.
- Rehearse register → assign → link to an incident → reassign/return → retire → dispose. Include the reactivation approval and disposal-evidence checks where applicable.
- Verify access with representative accounts: an asset manager, a team member performing custody actions and an ordinary user viewing only their assigned equipment. Test isolation from another tenant with the implementation team when validating a deployment.
- Extend adoption to stockroom transfers, repairs, contracts, inventory campaigns and equipment fulfilment once the core workflow and data are reliable.
- Add CI links only where Configuration Management is enabled, CSM Full is selected and the relevant permissions exist. Enable Analytics separately if reporting is required.
Deployment phases and checkpoints
The original delivery plan separates schema/security foundations, usable core workflows and operational extensions. It is a historical implementation plan, not a current feature checklist: unchecked tasks can describe functionality subsequently delivered. Use the functional description and user guide alongside later implementation notes to assess availability.
Phase 0 established the asset schema, tenant row-level security, role and module registration. The plan records applying migrations locally and to Railway production and verifying tenant isolation. This is implementation-team work; a tenant asset manager activates and configures an already deployed capability rather than running database migrations from the asset screen.
Phase 1 delivered the register, reference data, configurable statuses, assignment/return/transfer, audit trail, ticket links, CSV import/export and the user interface. The module became activatable after this usable core was complete. The plan's exit checkpoint is the complete core lifecycle working through the UI, with audit and access controls verified.
Phase 2 added operational depth: suppliers/contracts, repairs, stockroom levels and transfer confirmation, cost views, profile-based onboarding/offboarding, configurable intake, reconciliation, inventory campaigns and labels/scanning. Later implementation notes also confirm basic Problem linking and a repair-without-Problem warning. Broader model/category/manufacturer/firmware analysis and asset-model incident trends should not be inferred from that basic integration.
The following tenant rollout checkpoints are practical recommendations, not automated release gates: accept a small pilot; reconcile imported counts and custody; approve the core lifecycle; introduce advanced workflows one at a time; then review data quality and operational ownership after wider adoption. The original plan calls for production validation of Phase 1 before proceeding with Phase 2 development.
Permissions and visibility
Administrators have full access. Asset managers maintain the register and operational workflows, but status-list writes remain administrator-only. Elevated staff can assign, transfer and return within the applicable team-membership restrictions; this is not unrestricted asset administration. Ordinary users can read their own assigned assets, and cannot open another person's asset simply by knowing its identifier.
Campaign administration requires an asset manager or administrator. Checking an inventory item is available to authenticated checkers under the applicable tenant/module controls. Reporting still requires the separately enabled Analytics module and reporting permissions.
Planned expansion and boundaries
Phase 3 is a future direction: endpoint discovery, software asset management and licence compliance, cloud assets, lease/depreciation management, advanced refresh/TCO analysis and AI-assisted data quality. Do not treat these as delivered module features.
The plan also describes intentions beyond the documented current workflow, such as automatically creating return requests on user deactivation. The implemented onboarding/offboarding route uses employee profiles and Catalog Items; do not assume a deactivation event automatically recovers equipment.
Expected result
A tenant has a deliberately enabled module, clear responsibilities, validated pilot data and a staged path to broader use. The optional CI and Analytics capabilities are enabled only when needed and maintained.
Important behaviour
Activation is not endpoint discovery, a physical stocktake or proof of custody. Keep physical handover, wiping and disposal evidence as operational responsibilities. The module records their outcomes; it does not execute those external activities or replace accounting, procurement, MDM or full software licence management.
