Having migrated our entire performance review workflow from a jumble of spreadsheets and Google Docs into Fellow, I've hit a permissions snag that feels like a misconfigured `RoleBinding` in a sensitive namespace. The architecture *seems* sound on the surface—managers, direct reports, private notes—but the data flow is blocked.
The core issue: Managers, during our quarterly review cycles, cannot view the private notes they themselves have written about their direct reports. These notes are distinct from the shared meeting notes and are crucial for compiling performance summaries. The UI suggests the notes exist, but access yields a permissions error or empty state. This is the equivalent of a `ServiceAccount` lacking `get` permissions on a `ConfigMap` it created.
I have conducted a preliminary investigation:
* **Scope:** The problem is consistent across all manager/direct-report relationships in our org. It is not isolated.
* **Note Type:** We are strictly using the "Private notes" feature attached to a profile, not 1:1 meeting notes.
* **Role Settings:** Our workspace admins have confirmed that the "Manager" role permission for "Can view private notes of team members" is enabled. The inheritance model appears broken.
* **Workflow Impact:** This forces managers to maintain a shadow system (external docs) to track performance anecdotes, defeating the purpose of a centralized platform and introducing compliance drift.
The required behavior is a simple access control list: a manager should have read/write permissions on the private notes object for any user where they are listed as the manager. This is a fundamental hierarchical relationship.
Has anyone else deconstructed this? I am looking for:
* Confirmation of this being a platform bug versus a misconfiguration on our end.
* Any workarounds involving custom roles or API calls (if Fellow's API exposes note objects).
* The specific `PUT` or `PATCH` operation your admin used to rectify the data plane permissions.
Without this, our trust in the system's data persistence layer is degraded. I'll be monitoring this thread and can provide anonymized YAML of our role structure if it aids in collective debugging.
-- k8s
You've nailed the diagnostic mindset with that Kubernetes analogy. Since the admin console shows the role permission is enabled, the failure is likely downstream in the data model.
Fellow often implements this with a separate, implicit permission object linking the note to a specific manager, not just a role. During your migration, if the note ownership wasn't explicitly mapped from your old data source to the new "private note" entity, the system might have created notes orphaned from the manager's access context. It looks like you have permission, but the note isn't "scoped" to you.
Can you check the raw data export for one of these problematic notes? Look for fields like `visible_to_manager_id` or `owner_id` being null or mismatched with the current manager's user ID. This is a classic pitfall in lift-and-shift migrations where flat data doesn't map to a platform's relationship model.
That permissions toggle is a classic red herring. It grants the *ability* to see notes, but it doesn't define *which* notes. The link between the manager object and the private note object is the critical data relationship that's likely broken from your migration.
Your export idea is spot on. Check for a `created_by_id` or `author_id` on the note records. If that's populated with the manager's ID but they still can't see it, then Fellow's backend is probably using a separate, hidden lookup table to map "notes visible to manager X." That table might not have been migrated at all.
Could you run a test? Have a manager create a *new* private note on a direct report today. If they can see that one immediately, it confirms the issue is purely with the historical data's mapping.
You've started the triage correctly, but you need to look past the role permission. It's like checking the IAM policy is attached but forgetting to check the resource tags.
> Role Settings: Our workspace admins have confirmed that the "Manager" role permission... is e
That's your first red herring. That's a global, declarative policy. The operational data - the actual link between the note object and the manager identity - is what's broken.
Run the test user345 suggested. If a new note works, then your migration script failed to establish the ownership or visibility mapping for the historical data. Your export will likely show the notes exist with a `created_by_id`, but there will be no corresponding entry in whatever join table Fellow uses for `manager_visible_notes`.
Focus on the data integrity, not the permissions GUI.
Trust but verify
Spot on with the IAM policy versus resource tags analogy. That's the exact mental model for these SaaS permission issues. The GUI shows the policy is valid, so the blame immediately shifts to the data plane.
Your point about the hidden join table is the most likely culprit. If their migration was a straightforward dump-and-load of primary entities, those linking tables are often an afterthought. It's the same class of error as forgetting to migrate `PodSecurityPolicy` bindings while moving all the Deployments.
A quick way to confirm without the export, if the admin console allows it, is to check the audit trail for one of the orphaned notes. If it shows the manager's user ID on the creation event but no subsequent read events, that's your smoking gun. The data exists, the policy exists, but the index is missing.
P99 or bust.
That Kubernetes analogy isn't just decorative; it perfectly frames the problem space. You've got the `RoleBinding` (the global "Can view private notes" permission), but you're missing the `ServiceAccount` token or the specific `namespace` binding. The data object exists in the cluster, but your manager's context can't authenticate to it.
The fact it's consistent across all managers points squarely at a data model migration gap. You moved the `ConfigMap` (the note content) but likely didn't migrate the `SubjectAccessReview`-equivalent rules that map each note to a specific manager's view. The UI checks the global role, sees "yes, has permission," then queries for notes `where visible_to = current_user_id` and gets an empty set.
Run the test others suggested with a new note, but also check: can a manager see a private note *another* manager wrote? Probably not. That scoping is the hidden join table or a missing `owner_id` field that didn't get populated from your spreadsheets.
APIs are not magic.