How to Implement Assets in Jira Service Management for a Facilities Team

When an air-handling unit stops cooling an office, the facilities team needs more than a description of the problem. It needs to know which unit is affected, where it is installed, who services it, and what work has already been done.

Assets, used with Jira Service Management Cloud, connects that equipment information to the requests your team handles. For business teams using Jira Service Management, such as facilities, the starting point is a clear request process and a useful inventory. This hands-on tutorial walks a new facilities team and its Jira administrator through a small, practical implementation: model the inventory, import it, connect it to the service portal, and use it for repairs and preventive maintenance.

What you will build

By the end of this tutorial, employees will be able to report a facilities problem against a room or a specific piece of equipment. Technicians will be able to open the equipment record, find its location and maintenance details, and see the work recorded against it.

The worked example is an air-handling unit that stops cooling an office. You will build its asset record, connect it to the correct building and room, create a repair request, and prepare a view of upcoming maintenance.

Start with one building and 10–25 assets. The copyable practice CSVs at the end of this article include a second building so you can test that location filtering works. All sample organizations and records are fictional. Allow a working session for setup, then pilot the process with technicians before expanding it.

Assets holds the records of things. Jira Service Management holds the work performed on those things. A repair should be a work item linked to the equipment record. Each subsequent repair links to the same record. The same principle applies when legal teams link requests to contracts and vendors; facilities uses it for rooms and equipment.

1. Prepare the workspace and access

You need a Jira Service Management Cloud site with Assets enabled, a facilities service space, and an administrator who can configure Assets and Jira fields. Current Atlassian documentation includes Assets with paid Service Collection Standard, Premium, and Enterprise plans; check the site's actual entitlement and object allowance before importing the inventory. Assets availability

Use a company-managed service space for this tutorial. Name it Facilities and use FAC as its key if that key is available. An existing facilities space is fine. Jira is changing its terminology: your interface may still show project for space and issue for work item. Existing JQL queries retain their syntax. Jira terminology

Agree on these responsibilities before entering data:

• Create schema, object types, fields, and import mappings — Suggested owner: Jira/Assets administrator.
• Approve the model and own data quality — Suggested owner: Facilities manager.
• Update location, condition, and maintenance dates — Suggested owner: Facilities coordinator or nominated technicians.
• Submit a repair request — Suggested owner: Employees through the service portal.

Have the administrator grant appropriate Assets app access and schema permissions. Typically, schema managers administer structure/imports, schema developers maintain records, and schema users read them. Inspect the schema's initial access assignments: current documentation says product-access groups may be added as developers when a schema is created. A portal customer can use an exposed Assets field without having full Assets app access. Assets roles and permissions

Checkpoint: the administrator can open Assets, the coordinator can maintain the intended records, and a test employee can open the Facilities portal.

2. Design a small facilities model

Use four object types. An object type is a category, an object is one record, an attribute is one detail, and a reference connects records.

• Building — What it represents: A physical building; Example: CHI-HQ — Chicago Headquarters; Main relationship: Referenced by rooms.
• Room — What it represents: A room or serviceable area, including a roof; Example: CHI-HQ-ROOF — Headquarters roof; Main relationship: Building → Building.
• Vendor — What it represents: A service provider; Example: VEND-001 — Demo Climate Services; Main relationship: Referenced by equipment.
• Equipment — What it represents: An individually maintained item; Example: AHU-001 — Roof air-handling unit; Main relationship: Location → Room; Vendor → Vendor.

The relationship chain is:

Equipment: AHU-001
 ├─ Location → Room: CHI-HQ-ROOF
 │               └─ Building → Building: CHI-HQ
 └─ Vendor → Vendor: VEND-001

Repair work item: FAC-[number] → Affected equipment → AHU-001



Create Building, Room, Vendor, and Equipment as separate root object types. Their references describe where equipment lives. A schema-tree parent/child arrangement has a different purpose, including attribute inheritance; putting a type underneath another type does not connect individual equipment to individual rooms.

Use an enduring physical asset tag for equipment identity. Keep AHU-001 when its name, vendor, or location changes. Assets also generates its own object key, such as FACL-123; that system key is different from your physical tag.

3. Create the schema and attributes

From the app switcher, open Assets → Schemas and create a blank schema named Facilities, with the unique key FACL. Inside the schema, use the create control in the schema tree to add the four object types, choosing None as their parent. Create a schema, create an object type

Select each object type and open Attributes. Keep its existing Name attribute for a readable description, then add the attributes below. Type names in the tutorial are the system names to use in queries and mappings; match the spelling exactly. Create attributes

• Building — Attribute: Building code; Type: Text; Configuration: Required, unique; use as object label.
• Building — Attribute: Address; Type: Text; Configuration: Optional for the practice import.
• Room — Attribute: Room code; Type: Text; Configuration: Required, unique; use as object label.
• Room — Attribute: Building; Type: Object → Building; Configuration: Exactly one reference.
• Room — Attribute: Floor; Type: Text; Configuration: Allows values such as Ground and Roof.
• Vendor — Attribute: Vendor code; Type: Text; Configuration: Required, unique; use as object label.
• Vendor — Attribute: Service category; Type: Text; Configuration: For example, HVAC or Appliances.
• Equipment — Attribute: Asset tag; Type: Text; Configuration: Required, unique; use as object label.
• Equipment — Attribute: Category; Type: Text; Configuration: Use a consistent vocabulary.
• Equipment — Attribute: Location; Type: Object → Room; Configuration: Exactly one reference.
• Equipment — Attribute: Vendor; Type: Object → Vendor; Configuration: Zero or one reference.
• Equipment — Attribute: Status; Type: Status; Configuration: Operational, Under maintenance, Out of service, Retired.
• Equipment — Attribute: Criticality; Type: Select; Configuration: High, Medium, Low.
• Equipment — Attribute: Responsible team; Type: Text; Configuration: For example, Facilities.
• Equipment — Attribute: Serial number; Type: Text; Configuration: Preserve leading zeroes.
• Equipment — Attribute: Warranty expiry; Type: Date; Configuration: Optional.
• Equipment — Attribute: Last maintenance; Type: Date; Configuration: Optional.
• Equipment — Attribute: Next maintenance; Type: Date; Configuration: Optional.

For an Object attribute, select the target object type and a suitable reference type, such as a location or service relationship. Set minimum/maximum cardinality to 1/1 for a required single reference and 0/1 for an optional single reference. Reference attributes

In Attributes, open the code/tag attribute's … menu and choose Set as label. In its settings, enable Unique and set cardinality to 1/1. Do this for Building code, Room code, Vendor code, and Asset tag. Keep Unique off for relationship attributes: many assets may share a room or vendor. The label identifies the object in selectors; Name remains its readable description. Set a label, unique values

Open Facilities → Schema settings → Statuses / Status types → Create a status. Create Operational (Active category), Under maintenance (Pending), Out of service (Inactive), and Retired (Inactive); these category assignments are suggestions for this exercise. Return to Equipment's Status attribute and allow those four statuses. These asset lifecycle statuses are separate from the repair workflow. Configure the Criticality options too. Create statuses

If an attribute already exists, configure it instead of creating another with the same name. After the pilot, extend the model with purchase cost, manuals, inspection requirements, contracts, and replacement dates.

Checkpoint: Equipment has actual Object references for Location and Vendor, and its stable Asset tag is its label.

4. Import the practice inventory

Copy the four CSV examples in the appendix into separate UTF-8 files, preserving their headers and filenames. Import them in this order:

1. 01-buildings.csv — two buildings.
2. 02-rooms.csv — three rooms/areas, each linked to a building.
3. 03-vendors.csv — two fictional vendors.
4. 04-equipment.csv — four equipment records, including one retired unit.

The files use a header row, UTF-8 text, commas, and dates written as yyyy-MM-dd. Set that date format explicitly in the import; do not depend on the default parser. Replace the sample maintenance dates with dates appropriate to your exercise. Prepare import data

For each file, open the Facilities schema settings and its Import area, create a CSV import, upload the file, and turn automatic creation of object types/attributes off. Map to the object types you already created and enable the mapping before running it. Create an import structure

Map columns with matching names directly. Configure the stable identifier and the relationship columns as follows:

• Buildings — Import identifier: Building code; Relationship mapping: None.
• Rooms — Import identifier: Room code; Relationship mapping: Source Building code → Building reference; match Building.Building code.
• Vendors — Import identifier: Vendor code; Relationship mapping: None.
• Equipment — Import identifier: Asset tag; Relationship mapping: Source Room code → Location reference; match Room.Room code.
• Equipment — Import identifier: Same Asset tag mapping; Relationship mapping: Source Vendor code → Vendor reference; match Vendor.Vendor code.

Choose exactly one identifier per object type mapping. In the reference mapping's Simple mode, select the matching target attribute. If your screen uses Advanced AQL, the Room-code mapping can use "Room code" = ${Room code} against the Room target type. Those ${...} placeholders refer to columns in the import file. They are different from automation smart values. Map attributes and references

During the pilot, set Missing objects, Missing objects outbound references, and Empty values to Ignore. This keeps a partial file from removing records or clearing existing information. Deliberate clearing of an obsolete value then requires an explicit edit. Import mapping controls

After importing, open AHU-001. Its Location should open CHI-HQ-ROOF, that room should open CHI-HQ, and its Vendor should open VEND-001. Confirm the dates appear correctly. Then change only AHU-001's Name in the CSV and repeat its import: the existing record should update and the equipment count should stay at four.

Checkpoint: there are 11 practice objects in total, with four equipment records, and a repeat import does not produce duplicates.

5. Connect Assets to the Facilities request form

Create a request type named Report a facilities problem, backed by an appropriate service-request work type. Use these portal fields:

• Summary — Required?: Yes; Purpose: Short description of the problem.
• Description — Required?: Yes; Purpose: Symptoms and impact.
• Facilities location — Required?: Yes; Purpose: Room or area where help is needed.
• Affected equipment — Required?: No; Purpose: Specific equipment, when the employee knows it.
• Attachment — Required?: No; Purpose: A photo or supporting information.

Keep Affected equipment optional so a person can report a leak, temperature issue, or room problem without identifying a machine.

Ask the Jira administrator to create Facilities location and Affected equipment as Assets objects custom fields under Settings → Work items → Fields → Create new field. Open each field's Contexts and default values → Edit Assets object/s field configuration, select the Facilities schema, and configure single-object selection. Create Assets fields

For Facilities location, set Filter scope (AQL) to:

objectType = "Room"



For Affected equipment, set Filter scope (AQL) to:

objectType = "Equipment" AND Status != "Retired"



To offer equipment from the selected room, set Affected equipment's Filter work scope (AQL) to:

Location = ${customfield_12345.label}



Replace 12345 with the actual numeric ID of Facilities location. That field is an Assets selector, and Location is Equipment's Object reference to Room. In some interfaces, Filter work scope is still called Filter issue scope. Put the dynamic expression there; placeholders are not supported in Filter scope. Configure dependent Assets fields

Make both fields available to the relevant work type/screens and add them to the request type's Request form. Add them to the agent's work view too. Set search/display attributes to the useful identifiers and names; include equipment Status and Location for technicians. Scope the field contexts to Facilities where practical.

Test as an employee account: select CHI-HQ-ROOF and confirm AHU-001 is offered, the Annex equipment is excluded, and the retired unit is excluded. Change the room after selecting equipment and verify that an incompatible selection cannot remain unnoticed. If necessary, require it to be cleared/reselected during the pilot.

Portal field configuration affects which objects and details customers can see. Use only appropriate shared inventory in the exposed schema and test the employee experience; a convenient dropdown filter is not a substitute for designing access permissions. Portal field behavior

6. Run a complete repair exercise

Have a test employee submit:

Summary: Roof air-handling unit is not cooling
Facilities location: CHI-HQ-ROOF
Affected equipment: AHU-001
Description: The office is warm even though the unit is running. Please investigate.

As the facilities technician, open the request and then its linked equipment. Inspect the room/building, vendor, warranty, and maintenance dates. Record diagnosis, work performed, parts used, and any follow-up in the work item. Use internal notes for information intended only for agents.

A suggested workflow is New → Triaged → In progress → Waiting for vendor → Resolved. Adapt it to your team's process. Set Equipment's Status to Under maintenance or Out of service only when that reflects its actual condition. After repair, confirm the equipment is operational before changing its asset Status back.

Resolve the work item and inspect Connected Jira work items on AHU-001. The request should be linked to the same equipment record; switch the connected-work filter to include resolved items if needed. Work-item linkage, connected-work filtering

Checkpoint: the employee can submit, the technician can follow the references, and the completed repair remains discoverable from AHU-001.

7. Set up preventive maintenance

In the Facilities schema's advanced search, run this AQL to find operational equipment due by the end of the next seven days, including overdue items:

objectType = "Equipment"
AND Status = "Operational"
AND "Next maintenance" IS NOT EMPTY
AND "Next maintenance" <= endOfDay(7d)



Run a separate data-quality search for operational equipment with no maintenance date:

objectType = "Equipment"
AND Status = "Operational"
AND "Next maintenance" IS EMPTY



These examples use Assets Query Language (AQL), which searches objects. Jira Query Language (JQL) searches work items. Attributes with spaces need quotation marks. AQL syntax and date functions

For the initial pilot, have the coordinator review the due list and create an internal maintenance work item for each item needing service. Link Affected equipment, add the label preventive-maintenance, set a due date, and include the approved maintenance procedure. Check for existing open maintenance before creating another task.

Before completing maintenance, record the actual completion date in Last maintenance and set Next maintenance from the approved schedule. A repaired fault does not automatically mean scheduled maintenance was performed. The date fields hold the current schedule; linked work items preserve the detailed service history.

Optional: automate a daily maintenance review

Once the manual process works, open Facilities → Space settings → Automation and create a flow. Add the following components in this order:

1. Scheduled trigger: daily at a time and timezone agreed with the coordinator; leave the JQL trigger filter off so it runs once per schedule.
2. Lookup objects: select Facilities and enter the due-soon AQL above.
3. Advanced compare condition: {{lookupObjects.size}} is greater than 0.
4. Lookup work items: use the duplicate-check JQL below.
5. Advanced compare condition: {{lookupIssues.size}} equals 0.
6. Create work item: space FAC; work type Task; Summary Facilities maintenance review; label maintenance-review. Confirm Task is available in FAC and complete any other required fields. Use the description below.

The duplicate-check JQL is:

project = FAC
AND labels = maintenance-review
AND statusCategory != Done



The new task's description is:

Review these assets and create or update their maintenance work items:

{{#lookupObjects}}
- {{Asset tag}} — {{Name}} — next maintenance: {{Next maintenance}}
{{/}}



The description uses the list returned by Lookup objects. Assets smart values

The duplicate check prevents another scheduled review while one is open. The description is a snapshot: the coordinator should rerun the live Assets search when working the task. Complete the review after individual maintenance work has been assigned.

This rule creates a coordinator's review task containing a list; it does not attach every object to that task or replace the individually linked maintenance work items. Configure the rule actor to read the Facilities schema and browse existing FAC work items as well as create them. Test with one due asset, then run again while the review is open and confirm there is still one review task. Check the audit log.

Lookup objects returns at most 100 objects. Keep this exercise below that limit; split larger inventories into non-overlapping scopes and use distinct review labels per scope. Use one scheduled flow per scope and avoid overlapping runs. Automation lookup and create actions

8. Give the team useful views

Create Facilities queues or saved Jira filters for Open repairs, Waiting for vendor, and Preventive maintenance. For the last one, use:

project = FAC
AND labels = preventive-maintenance
AND statusCategory != Done
ORDER BY duedate ASC



To find open work affecting equipment marked High criticality, use an Assets-aware Jira query:

project = FAC
AND statusCategory != Done
AND "Affected equipment" in aqlFunction(
 "objectType = Equipment AND Criticality = High"
)



Replace FAC and the field name if your site uses different values. Test the query in Jira search before using it in a queue or dashboard. Use AQL in JQL

Track a small set of measures: overdue maintenance, open repairs, time to resolution, and assets missing a location or responsible team. Queue counts show work items; asset search counts show equipment. Multiple repair requests can point to one asset, so those counts measure different things.

9. Validate the pilot

Use these acceptance checks before adding more buildings:

• Follow AHU-001's references — Expected result: Correct room, building, and vendor open.
• Reimport unchanged identifiers — Expected result: Existing objects update; no extra equipment appears.
• Rename equipment in the import — Expected result: The same Asset tag still identifies the same object.
• Omit a practice row from a repeat import — Expected result: Ignore settings retain the existing record.
• Select different rooms on the portal — Expected result: Equipment options reflect the selected room.
• Search for retired equipment in a new request — Expected result: It is excluded from the active-equipment picker.
• Report a room problem with no equipment — Expected result: The request submits successfully.
• Complete a repair — Expected result: The equipment's linked-work history includes it.
• Change a maintenance date to yesterday — Expected result: Operational equipment appears in the due search.
• Run the optional review rule twice — Expected result: Only one open review task exists.
• Use a normal employee account — Expected result: Only intended portal inventory/details are available.

If a selector is empty, check its schema, field context, AQL, selected location, and user access. If a reference is empty after import, check the source code, target attribute, and import order. If duplicates appear, inspect the identifier mapping and accidental whitespace. If an automation fails, use its audit log to inspect actor permissions and required fields before rerunning it.

10. Keep the inventory reliable

Name an owner for each maintained attribute. For example, procurement owns serial number and warranty data, while facilities owns location, condition, and maintenance dates. Agree which data source wins before scheduling ongoing imports, so an old spreadsheet cannot silently overwrite current technician updates.

Review missing locations, duplicate tags, and overdue maintenance weekly during the pilot. Record moves when they happen. Retire records through their lifecycle status so historical work retains context. Add assets in batches only after the current batch passes the acceptance checks, and review the site's object allowance as the inventory grows.

Expand with separate maintenance-plan objects when an asset needs multiple recurring tasks, such as monthly inspections and annual servicing. A single Next maintenance date supports only one next scheduled activity per asset.

Pilot completion: one employee submits a request, one technician resolves it against the correct asset, one coordinator plans the next maintenance, and the facilities manager can review the resulting records and work.

Appendix: copyable facilities inventory CSVs

Save each block below as a separate plain-text file using the displayed filename, the .csv extension, and UTF-8 encoding. Keep the comma separators and first-row column names. If you edit the files in a spreadsheet, preserve identifiers and serial numbers as text, and save dates in yyyy-MM-dd format. All records are fictional practice data; replace sample dates before testing the maintenance searches.

The four files create two buildings, three rooms, two vendors, and four equipment records. Import buildings before rooms, and import both rooms and vendors before equipment so that references can resolve.

01-buildings.csv

Building code,Name,Address
CHI-HQ,Chicago Headquarters,Demo address - replace before use
CHI-ANNEX,Chicago Annex,Demo address - replace before use



02-rooms.csv

Room code,Name,Building code,Floor
CHI-HQ-ROOF,Headquarters roof,CHI-HQ,Roof
CHI-HQ-KITCHEN,Headquarters kitchen,CHI-HQ,Ground
CHI-ANNEX-MEETING,Annex meeting room,CHI-ANNEX,1



03-vendors.csv

Vendor code,Name,Service category
VEND-001,Demo Climate Services,HVAC
VEND-002,Demo Workplace Equipment,Appliances and AV



04-equipment.csv

Asset tag,Name,Category,Room code,Vendor code,Status,Criticality,Responsible team,Serial number,Warranty expiry,Last maintenance,Next maintenance
AHU-001,Roof air-handling unit,HVAC,CHI-HQ-ROOF,VEND-001,Operational,High,Facilities,DEMO-AHU-001,2028-09-30,2026-09-01,2026-10-03
COFFEE-001,Kitchen coffee machine,Kitchen equipment,CHI-HQ-KITCHEN,VEND-002,Operational,Low,Facilities,DEMO-COFFEE-001,2027-09-30,2026-09-15,2026-10-15
AV-001,Annex meeting room projector,AV,CHI-ANNEX-MEETING,VEND-002,Operational,Medium,Facilities,DEMO-AV-001,2027-06-30,2026-08-15,2026-11-15
AHU-OLD-001,Retired roof air-handling unit,HVAC,CHI-HQ-ROOF,VEND-001,Retired,High,Facilities,DEMO-AHU-OLD-001,2024-09-30,2024-08-01,
‍

Plan your facilities implementation with Avaratak

Ready to apply this model to your own facilities team? Book a 30-minute conversation with Avaratak to discuss your inventory, service requests, and implementation priorities.

‍