Jira Assets integrates nicely with Jira Service Management request forms. You can add an Assets object field to a request type and let customers select objects such as equipment, meeting rooms, vehicles, locations, or other resources stored in Assets.
There is one important limitation, though: Assets fields are not available to anonymous users on a Jira Service Management portal.
So what can you do if you want to keep your JSM portal fully open, without requiring customers to log in, while still letting them select an object stored in Jira Assets?
Disclosure: I am the Product Owner of Apwide Booking, the app presented as an alternative in this article. Apwide Booking is available for Jira Cloud only. It is free for Jira sites with up to 10 users and is a paid Marketplace app for larger Jira sites.
The limitation with Assets fields on anonymous JSM portals
Jira Service Management can be configured so that anyone can access the portal and submit a request without first logging in.
However, if your request form contains an Assets object field, anonymous users cannot use that field. Atlassian currently tracks this limitation through feature requests JSDCLOUD-10006 and JSDCLOUD-13422.
This can become a problem for use cases where the object the customer needs to select is managed in Jira Assets.
For example:
- a parking spot
- a meeting room
- a desk
- a company vehicle
- a piece of equipment
- any other bookable resource
One workaround is to maintain a separate select list and use Jira Automation to map the selected option back to the corresponding Assets object. This works, but it also means maintaining the same information in two places.
There is another option if these Assets objects represent resources that users need to book.
Selecting Jira Assets through a Booking field
Apwide Booking can use Jira Assets objects as booking resources.
Instead of adding a standard Assets field to the JSM request form, you can add a Booking field. The resources offered through that field can come directly from Jira Assets.
When an Assets object is displayed in the Booking field, users can see its name and Assets avatar, making resources easier to identify visually.
For example, a user could see a list of meeting rooms with their corresponding avatars and choose the room they want to reserve.
The important difference in this scenario is that the Booking field can also be used on a fully anonymous JSM portal.
The visitor does not need to log in before accessing the request form and selecting the resource.
Controlling which Assets objects are available
Of course, you probably don't want to expose every object from an Assets schema.
When configuring Assets as Booking resources, you can control which objects are available using AQL, and filter by Select or Object attributes.
You customers can then easily filter the objects from the anonymous JSM portal:
Booking field vs. Jira Assets field
The Booking field is not intended to reproduce every capability of Jira's native Assets field.
If your users are authenticated and you simply need a powerful Assets object picker, the standard Assets field provides more configuration possibilities.
The differences become more interesting when the selected object represents something that needs to be reserved.
Capability | Jira Assets field | Apwide Booking field |
|---|
Select an object stored in Jira Assets | ✅ | ✅ |
Display the object name | ✅ | ✅ |
Display the Assets avatar | ✅ | ✅ |
Filter which objects are available | ✅ | ✅ |
Filter based on object attributes | ✅ | ✅ |
Advanced Assets field configuration | ✅ | ❌ |
Use on an authenticated JSM portal | ✅ | ✅ |
Use on a fully anonymous JSM portal | ❌ | ✅ |
Consider resource availability | ❌ | ✅ |
Manage resource capacity | ❌ | ✅ |
Detect booking conflicts | ❌ | ✅ |
Reserve the selected resource | ❌ | ✅ |
Jira Cloud | ✅ | ✅ |
Jira Data Center | ✅ | ❌ |
So this isn't necessarily a replacement for the native Assets field.
For many JSM use cases, the native field remains the better choice.
But when an Assets object represents a resource that needs to be booked, the Booking field can cover a different requirement - particularly when anonymous portal access is important.
How does it work?
The setup is relatively simple:
- Keep your resources in Jira Assets.
- Configure them as resources in Apwide Booking.
- Define which Assets objects should be available using Assets Select and object attributes.
- Add the Booking field to your JSM request type.
- Allow anonymous access to the JSM portal.
Visitors can then open the request form, select an available Assets resource and submit their booking request without first logging in.
Your Assets inventory remains the source of the resource information.
One important distinction
There is an important technical distinction to keep in mind:
Apwide Booking does not make Jira's native Assets field available anonymously.
The limitation of the standard Assets field still applies.
Instead, Booking uses the configured Assets objects as resources and exposes them through its own Booking field on the JSM portal.
This is why it can be used for an anonymous booking flow even though the native Assets field cannot.
When is this useful?
This approach makes the most sense when three conditions come together:
Your resources are already managed in Jira Assets, users need to reserve or book those resources, and you want the JSM portal to remain accessible without login.
If you only need customers to select an Assets object and authentication isn't an issue, the standard Jira Assets field will usually be the simpler solution.
But for public booking scenarios, using Assets as Booking resources provides a way to keep Jira Assets as your resource inventory while still offering an anonymous JSM experience.
