Privacy policy | No Big Suite

Overview

This policy covers the No Big Suite marketing site, support communications, and the marketplace applications below. It describes the data categories we process, why we process them, where they are used or stored, how long they are retained, and when they are shared.

Marketing site

Data processed: Limited HTTP and network metadata necessarily processed by Cloudflare.
Purpose: Deliver and secure this website.
What we do not use: No forms, behavioral analytics, advertising cookies, or intentionally persisted visitor profiles.

Support communications

Cloudflare Email Routing is configured to forward inbound mail sent to support@nobigsuite.app to a Google Gmail mailbox. End-to-end delivery and mailbox monitoring have not yet been verified. Do not rely on this route for time-sensitive support.

Data processed: The configured support route processes the sender email address, message content, and any diagnostics you choose to supply.
Purpose: Forward your request to the support mailbox so the publisher can handle it and meet security or legal obligations.
Retention: Once a message reaches the support mailbox, it is reviewed at least annually and deleted when no longer reasonably needed, except records retained for an ongoing request, security incident, dispute, or legal obligation.

Please do not send secrets, access tokens, or customer content.

Product data practices

The product disclosures below list every current record, its purpose, storage location, retention, external egress, and uninstall behavior.

Shopify app

Stackproof Bundles

Stackproof stores the minimum merchant installation data needed to authenticate the embedded app, reject duplicate webhooks, and report aggregate offer performance. It does not retain customer or order payloads or identifiers.

Where data is sent: Runtime data stays between the Shopify APIs and the app's Cloudflare Worker and D1 database. No additional analytics or advertising service receives it.
After uninstall: Product-owned records are deleted on uninstall where each record states this.

Records and retention

Shopify installation sessions

Purpose: Authenticate a shop and, for online sessions, its associated Shopify user.
Location: Cloudflare D1
Retention: Shop domain, OAuth token, scopes, and optional Shopify user identifier remain for the active installation and are deleted on uninstall or shop-redaction.

Webhook replay receipts

Purpose: Prevent the same signed webhook from being processed twice.
Location: Cloudflare D1
Retention: Webhook identifier, topic, and shop domain expire after 24 hours.

Offer rules

Purpose: Configure bundle, volume, and gift behavior for Shopify Functions.
Location: Shopify-owned app metafields
Retention: Rules follow the Shopify installation and metafield lifecycle; Stackproof does not copy them into D1.

Storefront offer events

Purpose: Report offer impressions, selections, cart additions, and seven-day last-touch checkout revenue by currency.
Location: Cloudflare D1
Retention: Installation-scoped event IDs, offer IDs and kinds, timestamps, and browser-reported checkout attribution totals/currencies are deleted by an hourly cleanup 90 days after Worker receipt and on uninstall or shop-redaction. A durable installation-scoped pixel token and a 120-events-per-minute-per-Cloudflare-location installation limit protect public ingestion; neither authenticates purchases. No customer, checkout, order, or browser identifier is stored.

View the standalone data-practices page

Atlassian app

Estimate Gaps for Jira

This page describes the Estimate Gaps version in development, not the held Tallyfield Rollups for Jira Marketplace submission. The held submission still lists legacy storage and write permissions that have not been reconciled with this version. Estimate Gaps processes the Jira issue ID or key, summary, issue type, project, parent link, and Original Estimate presence only while answering the current viewer's request. It does not write Jira values, store panel results, log them, or send them outside Atlassian. The panel keeps only aggregate counts from the previous completed scan for one refresh comparison, then clears them on the next comparison, on failure, or when the panel closes. Earlier development versions left app-owned field values and Forge-hosted records. Removed field values have a 30-day cleanup target. Other Forge-hosted residuals follow Atlassian's lifecycle. The held submission described retention that could continue for up to 60 days after billing or trial ends. Development major 4 is installed on one site, and there is no production installation, so no customer production migration is currently required.

Where data is sent: The version in development has no external egress. Current request processing stays between Jira and Atlassian Forge.
After uninstall: Each record below explains its retention. We do not make a general immediate-deletion promise.

Records and retention

Current panel request data

Purpose: Read the issue in context and show only connected missing-estimate rows Jira returns to the person viewing it.
Location: Request memory in Jira and Atlassian Forge.
Retention: No application persistence, logging, export, or analytics retention. Refresh comparison retains only aggregate prior complete visible-gap count(s) in panel memory; no row data is retained, the completed-comparison baseline clears on the next comparison, all count memory clears on failure, and navigation or unmount discards it. Jira summaries can contain personal data and are processed transiently.

Development legacy Estimate Coverage/Rollups residuals

Purpose: Earlier development releases used app-owned derived-rollup fields; Forge KVS issue-to-project mappings and deletion markers; field-ownership, repair, and job state with temporary job pages; bounded aggregate analytics and recent project health; and completed hierarchy snapshots plus activation/unsupported markers. Those records supported rollup calculation, cleanup, recovery, and bounded operational status. The current panel cannot access or purge them and creates none.
Location: Existing development Jira app-owned fields and Forge KVS records only. No production installation currently appears, so there is no customer production migration.
Retention: Removed development fields follow a 30-day lifecycle. Legacy Forge-hosted residuals are subject to Atlassian's applicable Forge-hosted-storage lifecycle; the previously submitted Estimate Coverage contract described retention that could extend up to 60 days after the billing or trial period ends. The current panel creates no such records and makes no separate fixed post-uninstall retention promise.

View the standalone data-practices page

Sharing and service providers

We do not sell personal data to data brokers or use third-party advertising or behavioral analytics services. We share data with the providers below only to operate, secure, support, and meet legal obligations for the applicable service.

AtlassianJira, Forge, and Marketplace for the Jira application.
ShopifyThe app platform and app metafields for the Shopify application.
CloudflareWebsite delivery, the Stackproof Worker and D1 database, and configured Email Routing for support mail.
Google GmailThe configured mailbox for forwarded support mail; monitoring verification is pending.

Privacy requests

Email support@nobigsuite.app with the subject “Privacy request” to request access, correction, deletion, restriction, or objection, where applicable.

Please identify the relevant product and marketplace tenant. We may verify your identity and authority before acting. For data controlled by a Jira or Shopify customer, you may also need to contact that customer’s Jira or Shopify administrator or the relevant platform provider.

Start a privacy request

Changes to this policy

We will update this policy when our data practices change and will show the new effective and last-updated date here.