We can help frame, configure, introduce, integrate, and migrate our own add-ons. We do not advise on the Atlassian ecosystem or implement, integrate, migrate, administer, or configure Jira, Confluence, or any other Atlassian product.
If a prerequisite sits outside this boundary, your Atlassian administrator or chosen specialist remains responsible for it.
Every path begins with one named addly app and ends with app-specific acceptance evidence. The exact scope, availability, timing, and commercial terms must be confirmed in writing before any work starts.
Translate the intended use case into the selected app’s surfaces, settings, app-owned data, dependencies, and explicit stop conditions.
A bounded app scenario that can be tested.
Place the addly app in the agreed customer workflow and connect only the app-specific inputs and outputs covered by its documented capabilities.
The app joins a real moment of work without redesigning the Atlassian environment.
Prepare and apply the settings, rules, mappings, and in-app roles that belong to the addly add-on.
An app configuration tied to an approved record.
Guide the people who will administer or use the addly app through its key scenario, limits, and diagnostic path.
A team able to operate the app within the agreed use case.
Inventory, rehearse, transfer, reconcile, and, where technically supported, roll back only data and configuration owned by the addly app.
A controlled app migration with recorded checks and open limits.
A useful brief describes the app, the intended moment of work, and the conditions under which the customer can safely test it. It does not require addly to audit the wider Atlassian estate.
The customer decides and performs every required Jira, Confluence, identity, network, procurement, or third-party change outside the addly app.
The responsibility matrix prevents an app engagement from silently expanding into administration or transformation of the host products.
| Stage | addly | Customer | Exit gate |
|---|---|---|---|
| Frame | Describe the addly app boundary, app scenario, assumptions, and evidence needed. | Confirm the business scenario, owner, host context, and external prerequisites. | Written scope names what is inside and outside. |
| Prepare | Propose app settings, app-data handling, validation steps, and app-specific rollback conditions. | Provide authorized access, test data, approvals, and any required host-product configuration. | Inputs and stop conditions are complete. |
| Configure | Apply or guide only the agreed settings and connections inside the addly app. | Administer Jira, Confluence, identities, networks, and third-party products. | Configuration matches the approved record. |
| Validate | Demonstrate expected app behavior, record app defects, and reconcile app-owned data where relevant. | Run business acceptance and confirm organizational, security, and host governance. | Evidence, exceptions, and ownership are recorded. |
| Hand over | Provide the confirmed app-specific material and known limitations. | Approve production change, retain artifacts, and own ongoing host administration. | The app has an owner and an explicit next action. |
These models describe useful outputs. They are not a published package, included entitlement, availability commitment, delivery date, or service level.
Use case, app boundary, assumptions, prerequisites, exclusions, owners, and stop conditions.
Agreed app settings, rules, mappings, rationale, and validation status.
Test scenario, expected app behavior, observed result, exceptions, and next decision.
App-specific walkthrough, administration notes, known limits, and support diagnostic path.
Inventory, rehearsal, cutover, reconciliation, stop conditions, and rollback for eligible addly app data only.
Before work starts, a written brief must confirm which outputs are actually provided, their format, their owner, and the evidence required to accept them.
An engagement should close on evidence rather than a vague statement that configuration is complete.
These exclusions are part of the offer, not fine print. addly remains accountable for describing its own app and refuses to imply a wider professional-services practice.
If an answer would move the engagement beyond the addly app, the work remains with the customer or its chosen specialist.
No. addly designs and sells its own add-ons. Any implementation, integration, configuration, onboarding, or migration assistance is limited to those add-ons.
No. addly can specify the prerequisite and configure its own app. The customer’s administrator or chosen provider makes changes to Jira, Confluence, identities, networks, and other products.
No. A migration can cover only eligible data and configuration owned by a addly app. Host-product content, projects, spaces, users, and third-party app data stay outside scope.
Not on the evidence currently published. The page provides scope and deliverable models; operational availability, terms, price, timing, and included outputs must be confirmed in writing.
The brief records the prerequisite, owner, and acceptance evidence. addly can validate the app once it is present, but the customer remains responsible for work outside the app boundary.
Prepare a brief for one addly app and one observable scenario. The brief remains locally copyable even when compliant submission is not enabled.