Overview

Forge apps cannot use asApp() system context to call Assets APIs that require administrative permissions for creating or configuring resources such as: schemas, object types, object attributes, and reference types.

This blocks integrations that perform legitimate background work without an interactive user session, including scheduled triggers, async queues, remote-event handlers, and initial synchronization. The only confirmed workaround is offline user impersonation of a site administrator. That workaround is not durable: it creates a hidden dependency on an individual human account, and the integration can fail if that person leaves the site or loses the required permissions.

Environment

• Forge app
• Jira Service Management with Assets
• Background or remote invocation without an interactive user:
  • scheduled trigger
  • async queue
  • Forge Remote event handler
  • web trigger / workflow post-function
• Assets REST API endpoints requiring Assets administration
• App installed by an administrator and granted the relevant Forge/CMDB scopes

Steps to reproduce

1. Create and install a Forge app in a Jira Service Management site with Assets per Forge getting started for JSM.
2. Declare the necessary Assets/CMDB and Jira configuration scopes in the app manifest per Import Third Party data into Assets
3. Invoke the app from a context with no active user session. For example, a scheduled trigger, async queue, or Forge Remote event.
4. Use api.asApp().requestJira() or a FIT system token to call an Assets administrative endpoint, for example an endpoint for:

• object schema creation/configuration,
• object type creation,
• object attribute creation, or
• reference type creation.

5. Observe the API response.

Expected behavior

An app that an administrator has installed and authorized with the required scopes should be able to perform the authorized Assets administrative operations from supported non-interactive Forge contexts. In particular, the documented Assets import and async processing architectures should support initial configuration and ongoing operation without requiring the app to impersonate a named human administrator.

Actual behavior

The Assets API rejects the request because the Forge system user has only user-level permissions and cannot perform Assets administrative operations.

Observed response is a 401 Unauthorized:

{
  "errorMessages": [
    "Sorry, you do not have permission to perform this action."
  ],
  "errors": {}
}

Adding manage:jira-configuration does not resolve the permissions.

Requested resolution

• Enable Assets administrative endpoints for asApp() when the installed Forge app declares and has been granted the required scopes; or
• Provide a durable app/service-principal authorization model for Assets administration that is not tied to an individual site administrator; and

Workaround

Use Forge offline user impersonation with allowUserImpersonation and a site administrator account.

Limitations: This ties the integration to a real human account. The integration can stop working if that person departs, is deactivated, or loses administrative access.

Evidence and references

• Community: Getting user attributes from Assets asApp
  • A background asApp() query returns Assets user attributes as Unknown user, despite relevant scopes and successful Jira user access.
  • The documented answer confirms that background execution currently requires asUser with impersonation.

• Community: Forge apps cannot authenticate to the Assets REST API
  • Reproduces 401 Unauthorized against Assets endpoints despite CMDB read scopes and an installation upgrade.
  • Identifies the mismatch for scheduled triggers, web triggers, and workflow post-functions as contexts without a user session.
  • Requests that declared CMDB scopes authorize asApp() access to Assets APIs.

• Community: Which Assets import tutorial is current for async queues?
  • Documents developer reliance on the Assets import template and async-queue guidance for real-world, large-scale integrations.
  • Establishes why background invocation is not an edge case: it is needed to stay within Forge invocation limits when imports require chunking, paging, waiting, or large volumes.