Espresso Privacy Policy

Espresso keeps a small bounded diagnostic history for each run, so that an administrator can see whether a rule is working. This is stored in Atlassian Forge hosted key-value storage. The current implementation groups a rule by its configured source and target field identifiers and keeps up to 10 recent records for that rule.

Forge scopes storage per app installation. It is not a database operated by Totesoft, and Espresso contains no mechanism for Totesoft to read an installation's stored records.

1. How it is grouped
1. Records are grouped per rule. The storage key is derived from the rule's three configured custom field identifiers (source 1, source 2, target) — for example espresso:runs:customfield_10089.customfield_10090.customfield_10064. The key contains field identifiers only; it contains no issue data and no field values.
2. Because identity is the field triple, two post functions configured with the same three fields on different transitions share one history. Each record carries its own transition identifier and name, so the entries remain distinguishable.
2. How much

Up to 10 records per rule. The eleventh run displaces the oldest. Storage per rule is therefore bounded and does not grow over time.

3. What each record contains

Field	Example	Notes
timestamp;	2026-08-18T21:28:53.921Z	Rule execution timestamp
issue key;	ABC-22214	Identifies the issue that was transitioned
Transition identifier	11
Transition Name	In Process → Done
Operation	ADD	The configured arithmetic operation applied to the source values
Outcome code	SUCCESS, FIELD_NOT_AVAILABLE	From a fixed, closed vocabulary
Severity	ok, skipped, error
Outcome summary;	"Target field updated."	Fixed text, chosen by the outcome code
Technical detail;	HTTP 400; Jira did not accept field customfield_10064	See below
Retry count;	0	Jira retries performed during the run
Execution duration.	940 ms

The storage object also contains an update timestamp.

4. What a record never contains
1. Numeric source values
2. The calculated target value
3. Any user identifier — no account ID, name, email address, or display name
4. Any free-form text originating from Jira or from an exception

The "technical detail" field is assembled from an allowlist: an HTTP status code and a custom field identifier. Jira's raw error responses are deliberately not stored, because Jira often quotes the rejected value back in its error text, and that value derives from the customer's field data. This is enforced in code and covered by automated tests.

5. Who can see the stored records
1. Jira administrators — yes, by design. The last ten runs for a rule are displayed in that post function's configuration screen, under "Recent runs". There is no interface for browsing the underlying key-value store directly, but its contents are surfaced in the app's own UI.
2. Totesoft — no. Espresso provides no function, endpoint, or interface that reads an installation's stored records back to the vendor.

1. Application logs for regular operation

Espresso writes one structured log entry per run. It contains the same outcome information as the stored record: outcome code, severity, technical detail, issue key, transition identifier, rule identifier, retry count and duration.

Forge application logs are hosted through Atlassian's developer platform and are visible and can be accessed by authorized Totesoft personnel through the Atlassian developer console, as they are for every Forge app. They are used for diagnosing faults.

Field values are not written to logs during normal operation.

Two categories of text reach logs but never storage:

1. Jira error response bodies, only when verbose logging is enabled (below);
2. Exception messages, when an unexpected fault occurs. The stored record keeps only the error class (for example TypeError).

Totesoft does not operate a separate remote application server for Espresso. The reviewed production design declares no external network egress and no third-party analytics or error-reporting service.

2. Verbose logging
   1. Espresso supports a verbose logging mode, disabled by default.
   2. When enabled, log entries additionally include the numeric source values, the calculated result, and Jira's raw error responses.
   3. It is controlled by a Forge environment variable (ESPRESSO_DEBUG) that can only be set by Totesoft, per environment, using the Forge CLI. It is intended for diagnosing a specific reported fault and is not enabled as a matter of course.

Totesoft processes the data described above to:

1. provide and execute the configured calculation;
2. show administrators whether a rule recently ran and what outcome occurred;
3. validate configuration and troubleshoot field-context, permission, rate-limit, or Jira API failures;
4. protect the app and Jira site against invalid or unsafe writes;
5. respond to support and security requests; and
6. maintain, test, and improve the reliability of Espresso.

Totesoft does not sell End-User Data or use Jira issue content for advertising.

Espresso does not send End-User Data to an external Totesoft backend or to independent analytics providers in the reviewed design. Atlassian provides Jira Cloud, Forge execution, Forge hosted storage, and Forge logging. Atlassian's processing is governed by the customer's agreement with Atlassian and Atlassian's applicable privacy, security, and subprocessor terms.

Totesoft may disclose information when required by law, to protect legal rights or security, or with the customer's authorization. If Totesoft later adds an external service or subprocessor, this policy and the Marketplace Privacy and Security answers must be updated before that change is released.

Workflow configuration: retained by Jira according to the customer's workflow configuration and Atlassian's product behavior.

Run history: limited by the app to the 10 most recent records per rule. A new record removes the oldest record after the limit is reached.

Forge logs: retained for 30 days, which is Atlassian's current Forge developer-console retention period.¹ Any diagnostic material copied into a support ticket must follow the support-ticket retention rule approved by Totesoft.

Uninstallation: Atlassian currently states that Forge hosted storage is soft-deleted and retained for 28 days after uninstall.² Reinstalling does not automatically restore the prior data.² With customer consent, Totesoft may request relinking through Atlassian within 21 days of uninstall so Atlassian can process the request before the retention period ends.³

Customer-requested deletion: Espresso keeps only the 10 most recent run-history records per rule and overwrites the oldest record when a new one is stored. Totesoft does not have a separate customer-facing delete button for Forge key-value records. A Jira administrator who wants earlier removal of stored diagnostics should email support@totesoft.com from an authorized site-admin account. Totesoft will take the technically available steps, which may include coordinating uninstall. If the app is uninstalled, Atlassian soft-deletes Forge hosted storage and retains it for 28 days.² Reinstalling does not automatically restore the prior data.² With the customer's consent, Totesoft may request relinking through Atlassian within 21 days of uninstall.³ After that window, Atlassian permanently deletes the data under its standard retention and disposal policy.³ Espresso does not delete Jira issue fields, workflow configuration, or Forge logs that remain only in Atlassian's logging infrastructure.

Totesoft will not promise deletion methods that the app or Atlassian platform does not technically provide. Requests may require coordination with the customer's Jira administrator or Atlassian support.

Requests concerning access, correction, deletion, restriction, objection, or portability should be sent to support@totesoft.com. Totesoft will acknowledge a request within three business days. We may ask the requester to verify their identity and their relationship to the Jira site. Because Espresso data lives in the customer's Atlassian site, we typically need authorization from a Jira administrator before accessing, changing, or requesting deletion of installation-scoped diagnostics. Requests about Jira issue content will be directed to the relevant customer administrator. Requests about Espresso's Forge-hosted run history will follow the deletion process in section 8.

Because the customer controls the Jira site and issue content, Totesoft may direct an end user to the relevant customer administrator. Totesoft may require the customer's authorization before disclosing or changing installation-scoped data.

Espresso uses Atlassian Forge execution and hosted storage. Totesoft applies least-privilege scope review, environment access controls, code review, dependency management, and diagnostic minimization appropriate to the app. No method of storage or transmission is completely secure.

Report suspected vulnerabilities to security@totesoft.com. Do not include sensitive production values in the initial report.

Totesoft may update this policy when Espresso's functionality, permissions, storage, logging, legal requirements, or service providers change. The effective date above will be updated. Material changes should also be identified in release notes or other appropriate customer communications.