# Who can see the customer card

Almost every question we are asked about this app is one of two. An agent cannot see the card and nobody can work out why. Or somebody in a security review wants to know exactly who else on the site can read a customer's CRM details from inside a ticket. Both have the same answer, which is a ladder of checks, and it is worth reading it from the top.

The short version: the card is only ever offered to signed-in Jira Service Management agents, on a service management project, in a project that has finished setup and chosen a placement, to a viewer who can open the issue in front of them, and who holds the project permission the project administrator picked. Anyone who falls out of that ladder sees nothing at all.

## The floor, before any setting is consulted

Four things are true before the Permissions tab is read at all. None of them can be configured away, and no setting in this app can widen them.

* The viewer is signed in. Nothing this app adds is offered to anonymous visitors, and none of the three card placements permits unlicensed access, so somebody who reaches a request through the customer portal never sees the card.
* The project is a Jira Service Management project, and the viewer has service management agent features on it.
* The project has finished setup and has at least one placement switched on. The placement step says it plainly: "Until one of these is on, the card renders nowhere, including for you."
* The viewer can open the issue. Before anything is fetched, the app reads the issue as the person looking at it. If Jira refuses that read, the card shows nothing and no lookup happens.

![The order the checks run in](https://help.gocapable.com/images/att1439268937.svg)

## Narrowing the audience by project permission

The Permissions step of setup, and the Permissions tab afterwards, ask one question: "Who sees the card, on top of being able to see the issue." The answer is a single Jira project permission, chosen from four. It is a closed list rather than free text, so the screen can explain each one instead of asking an administrator to know Jira's permission vocabulary.

| **"Required project permission"** | **What the screen says about it**                                                               |
| --------------------------------- | ----------------------------------------------------------------------------------------------- |
| Agents in this project            | "Anyone with agent access. This is the audience the customer card is for." This is the default. |
| Anyone who can see the issue      | "The widest option. Every licensed user who can browse this project sees the card."             |
| Project administrators only       | "The narrowest option. Useful while you are still deciding what to show."                       |
| Users who can manage sprints      | "A team-lead shaped audience on projects that use it as one."                                   |

⚠️

**The widest option is not as wide as it reads** The three card placements are offered only to service management agents in the first place, and the Permissions tab can only narrow that, never widen it. "Anyone who can see the issue" therefore does not reach a licensed user without agent access on the project, and never reaches a portal customer, whatever the hint under it suggests.

## Restricting further to named Jira groups

Under the permission sits "Restrict to groups (optional)", a box of Jira group names. The help under it reads: "Jira group names, separated by commas. Leave this empty for no group restriction, which is the default: a group check costs a Jira call on the first render for each viewer." When groups are named, the screen restates the logic so it cannot be misread: "A viewer now needs the permission above AND membership of one of these groups. Both, not either."

* Empty means no group restriction. That is the default, and it is the default because the check costs a Jira call the first time each viewer loads the card.
* Group names are compared ignoring capitalisation and surrounding spaces. "Account-Managers" and "account-managers" are the same group to this app.
* Nothing checks that a name you type actually exists in Jira.
* The membership question is asked by the app rather than by the viewer, because reading another person's group membership is not something a viewer is entitled to do as themselves.

⚠️

**A misspelled group name hides the card from everybody** A name that matches no Jira group matches no viewer either, so the card quietly disappears for the whole project. There is no error on the settings page, nothing on the issue, and nothing in the site connections list to suggest it. If the card vanished the moment a group restriction was added, check the spelling against Jira before checking anything else.

## Everyone who gets in sees the whole card

There is no per-person field hiding. The Permissions step says so out loud, and counts the attributes it is protecting: "Everyone who passes this gate sees every attribute you chose on the previous step. Nothing on the card is hidden per person." If a value is too sensitive for the widest person in the audience, the place to fix that is the Fields tab, not this one.

## What somebody outside the audience sees

Nothing. Not an empty box, not a message, not a placeholder. The same is true for anyone who cannot open the issue. This is deliberate: "you are not allowed to see this" is itself a statement about the customer, and about whether the customer is in the CRM at all.

The same silence applies to an unfinished project. An ordinary agent looking at a project that has not finished setup sees nothing; only a project administrator is told which piece is missing, and given a link into the settings.

## How long a permission answer is remembered

A viewer's permission answer and their group membership are remembered for fifteen minutes, so a repeat view of a request costs no Jira call at all. Two consequences follow, and they pull in opposite directions.

* Changes an administrator makes to the audience settings take effect immediately. Editing the group list is not subject to the fifteen minutes.
* Changes made in Jira are not. Somebody who loses a permission, or is moved out of a group, can keep seeing the card for up to fifteen minutes. Somebody moved into a group can wait the same fifteen minutes to get in.
* An answer Jira could not give, because of a rate limit, an outage or a refusal, is treated as "no" for that render only and is never remembered. One bad minute upstream cannot become fifteen minutes of a blank card.

## Who can change the settings, and who can see the estate

Two screens carry configuration rather than customer data, and both are gated on the server rather than by hiding a menu entry.

* The project settings screen is for project administrators. The check is made live against Jira on every request, not read from a cache, so removing somebody's project administration takes effect at once. A refused call answers "Attio settings for this project are available to project administrators only."
* The site-wide list of connected projects is for Jira site administrators, enforced the same way: "The Attio connections list is available to Jira administrators only."
* No screen can act on a project other than the one it is open in. Every project identifier the app uses comes from the signed context Atlassian supplies for that screen, never from anything the browser sends.

---

## A few things worth knowing

* A group name that Jira does not recognise matches nobody, and the card disappears for the entire project with no error anywhere. Capitalisation and stray spaces are forgiven. A typo is not.
* Moving a person into a Jira group does not let them see the card for up to fifteen minutes, while editing the group list in settings applies at once. From the outside the two changes look identical, which is why the second one gets blamed for the first one's delay.
* A viewer outside the audience and a project with a broken setup produce exactly the same thing on screen: nothing. When an agent reports that the card is missing, the card itself cannot tell you which of the two it is. Open the same issue as a project administrator, who is the only person shown what is missing.

---

## Related

[The Jira permissions this app asks for](https://help.gocapable.com/attio-for-jira/the-jira-permissions-this-app-asks-for.html)

[What is never sent, logged or stored](https://help.gocapable.com/attio-for-jira/what-is-never-sent-logged-or-stored.html)

---

_When the card is missing, start at the top of the ladder. It is nearly always the placement or the group list._