# What is never sent, logged or stored A list of things that do happen is easy to write. A security review is usually more interested in the things that do not, and in whether anybody would notice if they started to. This page is that list. It is the counterpart to the page about what leaves Atlassian, and where the two disagree, assume this one is the constraint the app was built to. ## The reporter's email address * It is never printed on the card. Every state, including the states about not finding anything, says "this reporter" rather than naming them. * It never reaches the browser. The data a card is built from has no field that could carry an address, so no screen and no developer tools session can show it. * It is never written to a log. * It is never stored, and never put into a storage key in readable form. * It is never used to title a record either. A person with no name in the CRM is shown as their object and a short identifier, for example "Person 8f3a1b2c", rather than as their address. Where the app needs to remember which reporter a cached answer belongs to, it keeps a short one-way fingerprint of the address instead of the address. For company matching, the fingerprint of the domain is additionally mixed with the project identifier, so the same fingerprint cannot be looked up across customers. We would rather be exact than flattering about this: the fingerprint is not a cryptographic commitment, and its job is a narrow one, which is to keep an address out of a storage key that platform tooling can see. ## What the logs do hold The app logs outcomes, not values. A company lookup records whether a match was found and how many candidates there were. The domain itself is never recorded, because a domain written beside an account identifier names an identified person's employer. Error text coming back from Attio is kept out of the logs for a specific reason, not a general one: a validation error is entitled to quote the value that failed validation, and on the lookup that matters that value is the reporter's address. Only the machine-readable error type, code and status are kept, and the reader gets a sentence the app wrote. 📝 **What a logged failure does identify** Where reading a reporter's address fails, the app records that person's Jira account identifier. It is the safe half of the pair and it is what makes a failure traceable at all. The address is not written beside it, and neither is the domain. ## What no screen will show * The reporter's email address, in any state of the card. * The domain a reporter writes from. None of the messages about a domain that could not be matched names the domain, because a reporter's email domain identifies their employer. * A raw Jira account identifier. Where Jira will not resolve a name, the site connections list shows "Unknown user", and where a connection predates the app recording who made it, "Not recorded". * The Attio API key, on any screen, including the site connections list: "Every project on this site that is connected to an Attio workspace. Attio keys belong to the project that pasted them, so they are never entered or shown here: this page is for seeing the estate, not for administering credentials you do not hold." * Any attribute the administrator did not choose, from the customer's record or from the records it links to. ## What is stored, and for how long | **What** | **Where it lives** | **How long it is kept** | | --------------------------------------------------- | ---------------------------------------------------- | -------------------------------------------- | | The Attio API key | Forge secret storage, per project, encrypted at rest | Until the project is reset | | The project's Attio settings | The app's own storage | Until changed, or until the project is reset | | Whether the card may appear, and where | A property on the Jira project | Until changed, or until the project is reset | | A resolved CRM record and the rows built from it | The app's cache | Fifteen minutes | | The record type's attribute definitions | The app's cache | One hour | | A viewer's permission answer and group membership | The app's cache | Fifteen minutes | | The name and picture of whoever connected a project | The app's cache | Twenty-four hours | Nothing is copied out of Attio on a schedule. There is no background job, no queue and no timer: every value is fetched when somebody opens a request, then kept warm for the window above. A change to any setting that affects a card, from the record type to either domain list, invalidates the warm answer at once, so an administrator never has to wait out the fifteen minutes to see their own edit. ## What a reset removes "Reset to defaults", at the bottom of the Connection tab, deletes the API key, puts every stored setting back to its default, takes the card off every issue in the project, removes the project from the site-wide connections list, and erases everything the app had cached about that project's CRM records, attribute definitions and viewer permissions. Nothing in Attio itself is changed or deleted. A key you no longer want has to be revoked in Attio separately. ℹī¸ **Reconnecting to a different workspace is clean** Because a reset clears the cached records as well as the settings, a project that reconnects to a different Attio workspace cannot be served the previous workspace's customer data. ## What a reset deliberately leaves behind Four short-lived facts about Jira survive a reset, because they are answers about Jira rather than anything from the CRM or the configuration: whether a viewer can read a particular issue, who reports an issue together with the one-way fingerprint of their address, a person's Jira group membership, and a person's display name and picture. None of them can be reached again from the reset project's settings, none of them holds an Attio value, and all of them expire on their own and are re-read from Jira as normal. --- ## A few things worth knowing * "This card could not be built. The error has been logged." refers to the app's own failure, and the line it wrote names the project, the issue and that failure. It does not hold the reporter's address or the domain, so there is no point going to a log for the value that failed. * The rule is about the reporter's address, not about every address on screen. If an administrator puts an Email attribute from the CRM record on the card, that value is shown and becomes a link announced as "Send email to". That is customer record data somebody chose to display, and it is governed by the Fields tab rather than by any of the protections here. * Deleting a Jira project does not delete its Attio connection. The row survives on the site connections list with whatever it last knew and no project name, which is deliberate: it is how a leftover connection is found and cleared up rather than quietly persisting. --- ## Related [What data leaves Atlassian](https://help.gocapable.com/attio-for-jira/what-data-leaves-atlassian.html) [Who can see the customer card](https://help.gocapable.com/attio-for-jira/who-can-see-the-customer-card.html) --- _The whole of it: the address goes to Attio, and comes back as rows somebody chose._