Attribute Best Practices in JSM Assets

Attribute Types in JSM Assets

JSM Assets supports these attribute types:

User vs Object: When to Use Each

Use User type when linking to Jira users. This enables notifications to the linked user, permission-based visibility, and integration with Jira user management.

Use Object type when linking to Person objects in your CMDB. This is better for organizational data (reporting structure, departments), tracking people who are not Jira users, and maintaining historical records.

When to Use Each Type

Text vs. Textarea

Tip: Text fields are searchable and sortable. Textarea fields are harder to query.

Text vs. Select

Good Select examples:

Status: [Active, Inactive, Retired]
Environment: [Production, Development, Staging, Test]
Criticality: [Critical, High, Medium, Low]

Good Text examples:

Serial Number: ABC123456
Hostname: prod-web-03
Employee ID: E12345

Boolean: When Yes/No is Clear

Rule: If there might be a third option later, use Select.

Required vs. Optional Attributes

When to Require

Require attributes that are:

When to Keep Optional

The Minimum Viable Object

Every object type should have a small set of required fields that allow creation without blocking on missing data:

Too restrictive:

Server (all required):
  - Hostname
  - IP Address
  - OS
  - Owner
  - Environment
  - Data Center
  - Rack
  - Purchase Date
  - Warranty Expiration

Just right:

Server:
  - Hostname (required)
  - Status (required, default: Active)
  - IP Address (optional - assign later)
  - OS (optional)
  - Owner (optional - assign later)
  - Environment (optional)
  ...

Select Fields: Best Practices

How Many Options?

Ordering Options

Common Mistakes

Mistake 1: Too Many Attributes

Problem: 50+ attributes on an object type, most rarely filled.

Symptoms:

• Forms are overwhelming
• Data is sparse
• Users skip optional fields
• Reports are mostly empty columns

Solution: Start with 10-15 attributes. Add more based on actual need. Archive unused attributes (don't delete - they may have historical data).

Mistake 2: Freetext Chaos

Problem: Using Text when Select would work.

Active
active
ACTIVE
Running
In Use
Deployed
Production

All mean the same thing. Now your reports are broken.

Solution: Use Select with controlled values.

Mistake 3: Overloaded Fields

Problem: One field storing multiple pieces of information.

Contact: "John Smith (john@company.com) - 555-1234 - Ext 42"

Solution: Separate attributes:

Contact Name: John Smith
Contact Email: john@company.com
Contact Phone: 555-1234
Contact Extension: 42

Mistake 4: Duplicate Data

Problem: Storing the same data in multiple places.

Application:
  - Owner Name: Jane Smith
  - Owner Email: jane@company.com

Person:
  - Name: Jane Smith
  - Email: jane@company.com

Solution: Use an Object reference:

Application:
  - Owner: [Reference to Person object]

Mistake 5: Missing Context

Problem: Attribute name doesn't explain what's expected.

Date: ???  (Purchase date? Install date? Warranty date?)
Owner: ??? (Business owner? Technical owner? Data owner?)

Solution: Specific names with descriptions:

Purchase Date: "Date the asset was purchased"
Business Owner: "Person accountable for business decisions"
Technical Owner: "Person responsible for technical maintenance"

Good vs. Bad Attribute Design

Example: Server Object Type

Bad Design:

Good Design:

Attribute Checklist

Before adding an attribute, ask:

Good attributes are specific, typed correctly, and required only when essential. Bad attributes are vague, freetext when they should be controlled, and create data quality nightmares.