Queue Coverage — customer terms and processing agreement
Version 1.0 — 30 September 2026.
Agreement
For orders made through Atlassian Marketplace, the agreement consists of the Bonterms Standard End User Agreement (Version 1.0), unmodified, together with the Provider-Specific Terms and attachments below. It takes effect between the customer and the provider upon the customer's first order as provided in that standard agreement. This page does not itself accept an order or establish that the app is available for sale.
Standard agreement: https://www.atlassian.com/it/licensing/marketplace/end-user-agreement-v1
Provider-Specific Terms
Provider and product. Provider is Jon Ander Irazusta Iribar, trading as ProfitSignal Labs. Product is Queue Coverage for Jira. Legal notices may be sent to support@profitsignallabs.dev and the address in the Legal Notice.
Governing law. Spanish law applies, without excluding protections or jurisdiction rules that cannot lawfully be excluded. For disputes between businesses, the agreed courts are those of Donostia–San Sebastián, Spain.
Permitted use and documented limits. The Product observes queue membership for Jira Service Management Cloud. Administrators select 1–10 operational queues and active status categories. A check is bounded to 200 currently visible requests with a Customer Request Type. Administrators may add up to 200 current exclusions using predefined reasons and an expiry within 30 days. Configuration is bounded to 1,024 revisions per project. No candidate-JQL simulation, background monitoring or Jira writes are included. The interface is in English.
Review signals. Coverage describes the signed-in agent, selected queues and read interval. It is not an SLA, a guarantee against missed requests or an organization-wide measurement. Jira indexing can lag and reads are non-atomic. Exclusions alter the eligible denominator and must be reviewed by the customer. Partial reads cannot establish that a request is outside all selected queues. Customers remain responsible for configuration, access controls and operational decisions.
Attachments. The published product setup guide is the Documentation. The Support Policy and Security Measures below apply. The Data Processing Agreement below applies to Customer Personal Data processed on the customer's behalf. The Privacy Notice explains processing for the provider's own purposes and the service architecture. For personal-data processing, the DPA prevails over inconsistent terms to the extent required to protect that data.
Support and availability. No additional contractual uptime percentage is offered. Support response commitments must meet the Marketplace Partner Agreement: a response within 24 hours for requests identified by Atlassian as critical and within five business days for other requests. Response is not a promise of resolution within that time. This does not remove the obligations and remedies in the Standard Agreement or mandatory law.
Customer data use. The provider does not sell customer data, use it for advertising or use it to train AI models. The current app has no integration with an AI service.
Data Processing Agreement
Parties and scope. This DPA forms part of the Product agreement between the customer (controller, or processor acting for its controller) and the provider (processor, or subprocessor respectively). It applies only to personal data processed on the customer's behalf through the Product and associated instructed support conducted through an agreed channel covered by this DPA. The general enquiries mailbox must not be used to transmit customer project records or personal data from Jira.
Instructions and purpose. The agreement, documented configuration and authorized use are the customer’s instructions to retrieve and compare visible queue memberships, display and export observations, store configuration and optional personal run metadata, operate the service and provide instructed support. The provider processes data only on documented instructions, including transfer instructions, unless law requires otherwise. Where legally permitted, it will inform the customer in advance of such a requirement and if an instruction appears to infringe applicable data-protection law.
Details of processing. Operations include retrieval, comparison, display, user-directed export and Forge storage. Transient source data includes request identifiers, status, dates, assignee display name, queue metadata and membership. Stored configuration includes project and queue IDs, status categories, revision timestamps and exclusions containing numeric issue IDs, predefined reasons and expiries. Optional personal history stores only read dates, policy version and expiry; its key includes a pseudonymous hash of the actor account ID. History expires logically after 30 days and uses platform TTL. Configuration revisions do not expire automatically, including old exclusion records. No raw issue content, counts or scan results are stored. Data subjects may include staff, contractors and people referenced in Jira records. Special-category or criminal-conviction data is not required.
Confidentiality and security. The provider will ensure that persons authorized to process the data are subject to confidentiality obligations and will implement appropriate technical and organizational measures, considering the processing risks. The Security Measures below describe this release. Customer instructions do not authorize weakening those measures. The provider remains responsible for its applicable obligations even where the infrastructure is supplied by a third party.
Subprocessors. The customer authorizes Atlassian, acting under the Forge Terms and Forge Data Processing Addendum, to provide Forge runtime and platform operations. This is the current subprocessor register for the Product. The applicable Atlassian contracting entity and its onward subprocessors are identified in those documents and Atlassian’s published subprocessor list. No separate email provider is authorized by this DPA to receive customer project records; any additional support channel requires its providers and safeguards to be disclosed and covered before such records are accepted. The provider will impose applicable equivalent data-protection obligations on subprocessors and remains responsible as required by law. Additional direct subprocessors will be notified at least 30 days before processing begins, allowing the customer to raise a reasonable data-protection objection. The parties will seek a reasonable resolution before the new subprocessor processes that customer's data; unresolved objections require an agreed alternative or termination of the affected service under the agreement.
Assistance. Taking account of the nature of processing and information available, the provider will assist with data-subject requests and the customer's obligations concerning security, breach notification, impact assessments and consultation with authorities. It will forward requests concerning customer-controlled data and will not independently answer them except on instructions or where law requires.
Personal-data breaches. The provider will notify the customer without undue delay after becoming aware of a personal-data breach affecting the customer's data. Available information will include the nature and scope, affected categories, likely consequences, contact point, and mitigation taken or proposed. Information can be supplied in stages as investigation progresses. This does not transfer the customer's independent statutory notification responsibilities.
Return and deletion. At the customer’s choice, the provider will return or delete customer personal data at the end of service unless law requires retention. Source Jira records and exported reports remain customer-controlled. Users can delete their own run history. Removing or expiring an exclusion stops its effect but does not erase prior configuration revisions. Full configuration erasure and inaccessible history require an authenticated support process and paused use during cleanup. Forge retains hosted storage for 28 days after uninstall; reinstalling does not automatically restore that storage. History has logical expiry and platform TTL, whose physical deletion may lag. Backups follow platform schedules. Retained data stays protected; immediate physical backup erasure is not promised.
Verification. The provider will make available information needed to demonstrate compliance and allow and contribute to audits and inspections by the customer or its mandated independent auditor, subject to reasonable confidentiality and security arrangements that do not prevent statutory rights. The parties will use available documentation first where appropriate. Audit access must not disclose another customer's data.
International transfers. Transfers must use a mechanism permitted by applicable law. Atlassian's applicable Forge DPA and transfer provisions must be in effect for its processing. The Forge DPA includes the applicable Standard Contractual Clauses. This agreement does not itself authorize a new recipient or create a transfer mechanism by merely mentioning one.
Security Measures and Support Policy
The Product runs on Atlassian Forge. Jira reads use the requesting user’s current authorization. Backend entitlement checks protect production. Project administrator checks protect policy and exclusion changes. Conditional immutable writes reject version conflicts. Fresh source and configuration rechecks precede results and exports. Forge-hosted storage is scoped to each installation. Saved configuration and personal history are described in the Privacy Notice.
The app declares no external network destinations, scheduled scans, AI integration or issue-write permissions. The provider does not deliberately log issue content, queries, names or account identifiers. Bounded queries limit work per request. These statements describe implemented controls, not independent audit certification or a claim that all attacks have been ruled out.
Support: support@profitsignallabs.dev. Support follows the Marketplace Partner Agreement's response commitments: 24 hours for requests Atlassian identifies as critical and five business days for other requests. These are response deadlines, not guaranteed resolution times; no additional uptime percentage is promised. Send sanitized reproduction steps and approximate time. Security reports should omit exploit details or sensitive records until a safe exchange method is agreed. No public bug-bounty payment commitment is offered.
Start support requests with the action, time and a sanitized error message. Do not send project exports, issue summaries, account identifiers, credentials or customer records to the general mailbox. If a request requires customer data, a covered channel and minimal scope will be agreed first. Requests for access, return or erasure begin with minimal identifying information; no password or API token is required.
Subprocessor and platform references
- Forge DPA: https://developer.atlassian.com/platform/forge/resources/Forge-Data-Processing-Addendum.pdf
- Forge Terms: https://developer.atlassian.com/platform/forge/developer-terms/
- Atlassian subprocessors: https://www.atlassian.com/legal/sub-processors
- Forge storage lifecycle: https://developer.atlassian.com/platform/forge/storage-reference/
Forge hosted storage holds versioned configuration, exclusion identifiers and optional private run metadata. History has a 30-day logical lifetime; platform TTL deletion may lag. Configuration revisions have no automatic expiry. Platform log and infrastructure retention policies apply. Clearing a result, deleting history or uninstalling does not delete Jira records or user-exported reports.