Optimize your schemas for usage

Usage is measured by object count, so design choices that change how many objects you create affect your usage. Structuring your data well keeps it useful and keeps your object count proportionate to what you actually need.

This is design guidance rather than a clean-up exercise. The aim is a schema that reflects how your teams work, not the smallest possible number of objects.

Review what you track

Start by looking at what each object type is for and whether you still use it.

• Check that each object type earns its place. If nothing references an object type and no one looks at it, it may be recording detail you no longer need.

• Look for detail that could be an attribute instead of an object. Consider whether information needs to be managed, referenced, reported on, or retained independently. If it does not, recording it as an attribute of an existing object can avoid creating a separate object. If it does, keep it as its own object and use references to show the relationship.

• Review across all your teams, not only IT. Schemas covering employees, vendors, contracts, and locations grow the same way hardware schemas do, and are often reviewed less often.

  Example: Create a separate object when the item needs its own owner, lifecycle, references, reporting, or retained history. Otherwise, an attribute on an existing object may be enough.

Simplify where it helps

Once you know what you're tracking, look at how it's put together.

• Avoid repeating the same data across object types. Use references to connect related objects instead of duplicating their details. For example, reference a vendor object from each contract rather than restating the vendor on every contract.

• Reuse object types where you can. Reusing an existing type rather than creating a near-identical one keeps the schema simpler to maintain.

• Organize object types to reflect real relationships. A structure that matches how things actually relate is easier to navigate and less likely to accumulate duplicates.

• Use consistent naming. Consistent names for object types and attributes make duplicates visible instead of hiding them.

  Example: Prevent duplicate imported records. If you import employee, vendor, contract, or location data, use a stable identifier - such as an employee ID, vendor ID, contract ID, or location code - to match incoming records to existing objects. This helps an import update the right object instead of creating a duplicate.

Manage object lifecycle without archiving

Assets has no archiving capability, so archiving isn't a way to reduce usage. There's no archived state that removes objects from your count while keeping them available.

Deleted objects don't count towards usage, and sandbox objects aren't included in the count. Deletion does reduce your count, but it's irreversible, so it shouldn't be your first step. Decide what an object is for and how long it stays useful before you decide to remove it.

Example: Update the current object instead of creating another current record. If an employee changes team or a vendor moves into contract review, update the existing object's attributes or references. Do not create a second object just to represent its current state. If you need to retain a history of the change or manage the related item independently, model that information deliberately rather than overwriting or duplicating the object.

Monitor the result

After you change your schema, check the effect on your object count in Assets settings under App usage, or in Atlassian Administration under Insights, then Platform usage. For how the count is worked out and what's excluded, see Assets usage and how it works.

For the technical limits that apply to every site regardless of your plan, see Manage Assets usage and limits.

Get more capacity when needed

Design changes aren't always the right answer. If your schema reflects what you genuinely need to track, adding capacity is the better option. See Manage the usage limit for Assets.