What data leaves Atlassian

This is the page to hand to whoever is filling in the security questionnaire. It lists every destination the app declares, what goes to each, and which ones are declared as carrying end-user data.

The honest headline first. The reporter's email address, or only the domain part of it, is sent to Attio as the value that finds the record. That is the product working, not a side effect, and there is no version of it that keeps the address inside Atlassian.

#The path a card takes

Every Attio call is made by the app's server, never by the browser. That is why the Attio key never needs to reach the page, and it is why a reader with developer tools open sees rows of values and no credential and no address.

#Every declared destination

The app calls one Attio API address, and there is no regional variant of it for the app to choose. What Attio then does with what it receives is governed by your own agreement with Attio, and nothing in this app changes it.

#The lookup value, exactly

• Matching a person: the whole address, trimmed of surrounding spaces and lower-cased.

• Matching a company: everything after the last @, lower-cased, with a trailing dot removed. The lookup also offers shorter forms of that domain, up to four labels deep, and lets Attio discard the ones that match nothing.

• Never looked up at all: any domain on the project's ignored list, which ships with a long list of free-mail and consumer providers; Microsoft 365 tenant domains; and Apple Hide My Email relay addresses. The last two are refused whatever the lists say, unless the exact domain is added to "Domains to match anyway".

• The app makes five kinds of read against Attio and writes nothing: it identifies the key, lists the workspace's objects, reads one object's attribute definitions, queries records to find a match, and queries records to resolve links.

#What the browser is given

The browser never receives a raw CRM record. The server resolves the record, takes the attributes the administrator selected in the order they chose, and sends only those. Unselected attributes on the record, and on the records it links to, never leave the server.

The same restraint applies where it would be convenient not to. When several records match, each candidate is offered with its title and one line of detail, and that line is the date the record was added to Attio. No CRM field is used to tell candidates apart, and the address is never used, because every candidate matched the same address anyway.

#The Attio key never reaches the page

The key is held in Forge secret storage, per project, encrypted at rest, and is never written to a Jira field, a project property or an issue. The settings screen is told only whether a key exists, so no screen in the app can display, copy or export it, including for the person who pasted it. The Connection step says who holds what: "This key belongs to this Jira project alone. Other projects on this site connect their own workspace, and a site admin can see that a connection exists but never the key itself."

A key of the wrong length never leaves Atlassian at all. An Attio workspace key is exactly 64 characters and the browser checks that before spending a call: "Nothing was sent to Attio. Copy the key again, including the whole string."

#The test address on the Fields screen

The preview beside the field picker is a real lookup. Whatever address is typed there goes to Attio exactly as a reporter's address would, so that the real values can be shown. It is never cached and never logged, and the screen is explicit about whose address it should be: "Only the part after the @ is looked up, so any address at a customer's domain gives the same answer. This is your own test address, not a reporter's."

#Pictures on a record

A picture on a CRM record can be hosted anywhere, because the attribute holding it is ordinary text and an administrator may nominate any text attribute. Rather than letting the browser reach an unpredictable host, the card fetches pictures through one Capable-controlled image service, which is given the picture's address and the viewer's own short-lived session token.

• It refuses anything too large, and anything whose file type is not on its allowed list.

• It blocks addresses on private networks.

• It tells the browser it may keep the image for an hour, so opening the same customer's next request costs nothing.

• Anything it will not serve becomes coloured initials on the card. There is no broken image and no error.

• A viewer Jira cannot identify is issued no token, so pictures do not load for them and the card falls back to initials.

#Crash reporting

The app declares error reporting to Sentry from both the browser and the server, categorised as analytics and declared as carrying no end-user data. Messages coming back from Attio are never passed into it, or into any log: the app substitutes its own sentence and records only the machine-readable error type, code and status.

#A few things worth knowing

• The test address on the Fields screen is a live lookup against your CRM, not a simulation. Type your own address, or a test record's, and never a customer's, because whatever is typed there goes to Attio exactly as a reporter's would.

• Company matching does not send only the exact domain. It offers shorter forms of it as well, up to four labels deep, which is how a reporter at a subdomain finds a company stored at the parent domain. If you are auditing what values leave, audit the family, not the single string.

• An administrator can nominate any text attribute as the record's picture. Whatever web address it holds is then fetched through Capable's image service for every agent who opens that customer's requests. A nominated attribute holding something that is not a public image address shows initials, which looks identical to a record with no picture at all.

#Related

One destination receives the address. The rest receive code, pictures and crash reports.