Who Can See the Salary Field
A 60-person company runs hiring in Asana. The 'Hiring' project is shared with the whole company so anyone can refer candidates. Tasks represent candidates. A custom field 'Compensation band' (single-select: Band 1–5) is used by the hiring manager and finance. A second field 'Interview notes' is a long-text field where interviewers paste feedback. The team discovered that any employee can open a candidate task and read both the compensation band and the interview notes. Legal flagged this. The team wants: everyone can see that a candidate exists and refer; only the hiring panel (8 people) can see interview notes; only the hiring manager and finance (3 people) can see compensation band. They also want interviewers to keep adding notes easily.
1. Explain why field-level restriction cannot be solved by project sharing settings alone, and propose a structure that meets all three visibility requirements.
Read the worked answer
Project sharing is all-or-nothing at the project level: if the whole company is a member so they can refer, they can see every task and every field on it. There is no per-field permission on a shared project that says 'field X is visible only to group Y.' So the requirement set is internally contradictory within one project.
The resolution is to split by sensitivity into separate projects and control membership per project:
- Referrals project (company-wide): minimal task - candidate name/requisition ID and a link or reference to the restricted task. No compensation, no notes. Everyone can create here.
- Hiring panel project (8 people): holds interview notes. Interviewers are members; they add notes directly. Company at large is not a member.
- Compensation project (3 people): holds the band. Hiring manager + finance only.
Link the tasks (e.g., via a shared ID or a multi-homed task where supported) so the panel can navigate, but the restricted data lives only where the restricted audience is a member. Interviewers keep adding notes 'easily' because they're members of the panel project - the ease requirement is met by membership, not by exposing the field broadly.
2. A teammate suggests 'just make the fields private.' What are the practical limits of that, and what governance must accompany the split?
Read the worked answer
'Private fields' (where the platform supports restricting a field to certain people) help, but they are a narrow tool with real limits:
- They typically restrict who can see/edit the field's values in the UI, but don't stop a determined member from exporting or screenshotting a task they can open, and they don't fix the fact that the task itself (and its comments) may still expose sensitive context.
- They don't compose well with company-wide membership: if 60 people are project members, you're relying on a field-level toggle as the only barrier - a single misconfiguration (field added to a form, a chart, an export) leaks it.
- They don't cover free-text comments. Interview notes pasted into a comment on a company-visible task are visible regardless of field settings.
Governance that must accompany the split:
- Membership review on a cadence - the panel and finance projects' member lists are the real access control; audit them quarterly and on role changes.
- No sensitive data in comments or task names on the broad project; state this as a rule and enforce it.
- Form and template hygiene - ensure no form or template copies restricted fields into the broad project.
- Offboarding - removing someone from the company must remove them from the restricted projects; a leaver who retains project membership is the most common leak.
- Document the model - one page saying which project holds what and who may be a member, so the next person doesn't 'helpfully' re-share the hiring project with everyone.