Review & approval

When you submit an IrisX App version, it goes through review before it becomes available in the Trackunit Marketplace. This page explains what happens after you submit, what is checked automatically, and what a reviewer looks at.

What happens when you submit

1. You submit a new version of your app package. Automated validation runs immediately — if the manifest does not meet the validation rules, the submit is rejected with an error for you to fix.
2. Private apps are auto-approved — no human review is required, and the app becomes available as a Private App. See When a version is auto-approved for the exact conditions.
3. Marketplace IrisX Apps go to review. You request a review, a Trackunit reviewer inspects the submitted version, and then either approves it or shares feedback about what needs to change.
4. Once approved, the app becomes available in the Trackunit Marketplace. If you receive feedback, address it and re-submit a new version.

When a version is auto-approved

Auto-approval is a platform decision made from your manifest and your publishing identity. It does not depend on how you authenticated, so a publish from CI and a publish from the browser reach the same outcome for the same app.

A version is auto-approved only when all of the following hold. If any one of them fails, the publish still succeeds — the version simply waits for manual review.

Condition	Waits for review when
marketplace.showInMarketplace is false	It is true. A Marketplace app always goes to review, even if accountIds names a single account.
Install targets are configured	Neither accountIds nor allowOrganizationIds is set, or accountIds is an empty list.
accountIds is a specific list	It is "ALL_ACCOUNTS".
Every account is your publishing account or one of its descendants	Any account sits elsewhere — including a sibling account under a shared parent, which is not in your hierarchy.

If you use allowOrganizationIds instead of accountIds, the version is auto-approved when every organization listed is your publisher's own organization, and no account hierarchy is consulted.

Hierarchy means your subtree, not your company

The hierarchy is the account you publish from plus everything beneath it. An account alongside yours under a shared parent is outside it, and the skip is recorded as account-ids-outside-hierarchy. If you want a Staging account covered by a production app's install list, create it under the account you publish production from.

Response time

Review requests are normally handled within one business day of the request being submitted.

Validation rules

These rules are enforced automatically when you publish. A version that fails any of these checks cannot be published.

Installation config

Field	Requirement
pricingPlanPolicy or pricingPlans	At least one must be present
accountIds or allowOrganizationIds	Exactly one must be present (not both)
accountIds	Must be an array of account IDs or "ALL_ACCOUNTS"

For guidance on choosing installation policies and targeting accounts, see Controlling marketplace behavior.

Marketplace metadata

Field	Requirement
marketplace	Required (object)
marketplace.name	Required
marketplace.description	Required
marketplace.fullDescriptionPath	Required, and the referenced file must exist in the assets/ directory of the package

Scopes

Each scope must be a recognized value from the list of declarable scopes, and is validated against the authorization server on publish. Scopes are required when tokenCallback is set; otherwise an app that needs no API access may omit them.

Custom field definitions

If customFieldDefinitions are present, they are validated against the Custom Fields API on publish. Errors reject the publish; warnings are returned to you.

What reviewers check

Beyond the automated validation above, a reviewer verifies the following when reviewing a Marketplace IrisX App version:

• Extensions: extension types, IDs, and menu item labels are appropriate.
• Dependencies: no unexpected or suspicious packages in dependencies and devDependencies.
• CSP / valid domains: listed domains are legitimate and expected for the app.
• Scopes: requested API scopes are justified by the app's functionality.
• Custom field definitions: field keys, entity types, and editability settings are appropriate.
• Installation targets: accountIds / allowOrganizationIds and pricing plan configuration look reasonable. There is currently no way to verify these against a pre-agreed specification, so it helps to include the expected installation targets in your review request.
• Diff against the approved version: when re-approving an updated version, particular attention is paid to what changed since the last approved version.

Not covered by review (for now)

• Runtime behavior — review is based on manifest metadata, not running the app.
• App performance or reliability.
• Security posture of external domains listed in CSP / valid domains.
• Client-side code quality.