Use assets and categories to understand what your customers depend on

An asset describes something your team supports, such as equipment, a software product, or a supported installation. Asset categories organize those items into useful groups. In B2B support, connecting the supported item with its customer relationships and case history helps agents investigate a recurring issue with the right context.

Understand assets, categories, and relationships  ·  Inspect an asset during an investigation  ·  Maintain useful asset records  ·  Investigate a recurring equipment issue  ·  Choose a manageable structure  ·  Create an asset and add its customer relationships  ·  Model a supported installation without confusing the category and item  ·  Common problems

Understand assets, categories, and relationships

The available fields and selection rules depend on your asset and case-policy configuration. Do not assume that every item is visible to every agent or customer.

Inspect an asset during an investigation

1. Open the authorized asset link from the relevant customer or case context. Confirm you are viewing the item associated with this issue.
2. Review Overview, including the category, identifying details, parent, expiry, and visibility information that is present.
3. Use Companies and Contacts to check the customer relationships. A similar asset name is not enough to establish that a customer uses the item.
4. Review the available Recent History and authorized case links. Compare symptoms, environment, and resolution before concluding that separate cases share a cause.
5. Use Audit when available and permitted to understand relevant changes. Do not infer historical values that were never captured.

Maintain useful asset records

1. Search the existing inventory before creating a new item. Decide whether this is a distinct supported asset, a version, or an attribute of an existing record.
2. In the relevant asset configuration, choose a meaningful category and enter the fields needed by your support process. Avoid adding unused fields merely because they are available.
3. Set the appropriate parent and customer relationships. Review expiry and customer-visible naming or visibility where applicable.
4. Save through the permitted editor. Reopen the asset and verify the values and related company/contact records.
5. Test asset selection in the applicable case form with an authorized agent and representative customer context. Case-policy settings can control whether an asset field is shown or searchable.

Investigate a recurring equipment issue

Useful outcomes to track include fewer misidentified assets, complete customer relationships, and how often known solutions are reused. These are measures your team can observe; they are not guaranteed performance improvements.

Choose a manageable structure

• Keep category names understandable to agents. A short, stable taxonomy is easier to maintain than many overlapping groups.
• Use parent relationships for a real hierarchy; use fields for attributes. A category should not be the only place an important version detail is recorded.
• Review relationships when customers change supported products or contracts. Stale associations can lead an agent to investigate the wrong environment.
• Keep internal engineering detail separate from external labels and visibility. Verify customer-facing behavior using the intended audience.

Create an asset and add its customer relationships

1. Search for the supported item first. Asset editing requires the relevant role permission. Where permitted, use the global New → Asset action, or New Asset from administrative Assets.
2. Enter a clear name, choose the appropriate category, and complete required fields. Use a parent only when it represents a real hierarchy. Check internal and external naming separately.
3. Choose Save Asset. Reopen the saved asset and confirm the fields. Linked-customer tabs are not available on a new unsaved asset.
4. For an existing record, open Edit Asset when needed. Use Linked companies or Linked contacts to search for the intended customer and select it; in the record flow, review the Add link confirmation.
5. Review the relationship immediately. Adding/removing these links is a separate operation from saving asset fields. Closing the editor without Save Asset does not undo a relationship that already succeeded.
6. Open a representative case form with the intended customer and check whether the asset is available under that case policy. Verify the exact item, not just a similar name.

Model a supported installation without confusing the category and item

Suppose your team supports industrial controllers. “Controllers” can be a category; a particular controller model, installation or supported version can be an asset according to your agreed inventory design. A parent can express a meaningful model/version relationship. A serial number or site identifier belongs in the appropriate maintained identifier/field rather than being guessed from a category name.

For a restart incident, confirm which item the customer actually uses and the relevant version. Link the case to that item where the case form supports it, then compare earlier cases. Two records in the same category may have different firmware, configurations or service entitlements; do not prescribe a fix just because the category matches.

When the investigation is resolved, retain the customer-specific outcome on the case and write reusable knowledge around the verified environment and procedure. During an account change or equipment replacement, review the customer relationship separately from the asset’s descriptive fields. This keeps the next case from being associated with an item the customer no longer uses.

Common problems

Continue learning

• Configure asset categories
• Configure assets and their customer relationships
• Configure asset fields in case policies
• Review company and contact context
• Turn a verified resolution into knowledge