Approval Drift
by ProfitSignal Labs

Approval Drift — customer terms and processing agreement

Version 1.0 — 1 October 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 Approval Drift for JSM. 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 reports material field changes after native JSM approvals. Administrators save 1–12 supported scalar fields in a versioned project policy. Input batches accept up to 200 request keys from one project; evidence expires after one minute and large batches may need narrowing. Per-request limits are 1,000 approvals, 2,000 changelog records, 100 source calls and a 20-second reader budget. Up to 128 policy revisions are supported. These bounds are not throughput or availability guarantees. Only personal internal reviews are stored; no shared approval engine, automatic Jira scans, workflow changes or Jira writes are included. The interface is in English.

Review signals. Reports concern the current user, latest native approval cycle, selected policy and read time. They do not determine legal validity, grant or revoke approval, sign a document, certify compliance or guarantee that no change was missed. Rules are effective from their saved time; missing, ambiguous, unsupported or stale evidence cannot establish an all-clear. Reads are non-atomic. Customers remain responsible for approvals, 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 instruct the provider to read visible native approval and field-change evidence, display and export observations, store project policy and optional personal review annotations, operate the service and provide instructed support. Processing occurs only on documented instructions, including transfers, unless law requires otherwise. Where legally permitted, the provider informs the customer of such a requirement and instructions that appear to infringe data-protection law.

Details of processing. Operations include retrieval, comparison, display, user-directed export and Forge storage. Transient data includes issue/project identifiers, supported field values/schema, native approval records and changelogs, which may contain actor identities. Stored policies contain project/field IDs, types, versions and effective times. Personal annotations contain issue/approval IDs, policy version, fixed disposition/reason and read/save/expiry timestamps; a pseudonymous account hash scopes their keys. The real account ID and oldest data time are retained for Atlassian personal-data reporting. Review records expire logically after 30 days and use platform TTL. Deletion markers last at most 31 days. Policies do not expire automatically; minimal erased-version markers remain. Raw field values, approver names/emails and source snapshots are not retained. Data subjects may include staff, contractors and people referenced in Jira records. Special-category and 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 erase their own annotations; project administrators can erase configuration in bounded batches. Minimal version markers prevent stale writes. Inaccessible records require an authenticated support process and paused use during cleanup. Manual erasure hides prior reviews using a deletion watermark; two empty queries at least one minute apart confirm cleanup, and new saves wait until that confirmation. Forge retains hosted storage for 28 days after uninstall; reinstalling does not automatically restore it. Platform TTL and backups may lag logical deletion; 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

An hourly bounded privacy-maintenance function reports only account IDs and oldest retained data times to Atlassian, follows its reporting interval, and handles requested erasure. It does not scan Jira. Personal history reads and saves fail closed when privacy maintenance is overdue or erasure is pending.

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 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 hosted storage holds versioned configuration, protected field identifiers and optional personal review annotations. 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.