Candidates should be a table in Coda where each candidate is a row.
However, I cannot control who can view each row in the table (only the people involved in hiring a specific person should be able to view – at least, to prevent the candidate from viewing their own discussion after they were hired).
If I’m understanding correctly, you want one use-case for your recruiters to work with candidates, and another use-case is for candidates to be able to see their status and applicant information, correct?
If so, with the current permissions functionality (March 2022) you’ll want to separate these into two different documents and use cross-doc to limit the data so that the candidates do not have access to that which they should not.
Filters and locking permissions are another approach, however if they have access to the doc then they have access to the underlying data, it’s not secure and personally I wouldn’t risk it if your recruiter comments have anything sensitive in them.
I interpret it not as letting every candidate view their own record, but rather:
a bunch of people apply to an HR position
one of them gets hired
we don’t want that person viewing the details of the evaluation process of their own application, now that it’s their turn to use this ATS doc
I’m in the same boat right now actually. We’re small so I’m just going to create a new copy of the ATS template I think and start from scratch after they’re hired.
You can filter tables so that, for example [Hiring Managers Column].Contains( User() ) if you only want to show candidates where the currently-logged-in user is in the list of hiring managers. But a savvy Coda user will always be able to view the full table of all candidates.
Ah I see. I don’t know a good solution to this. You could copy that particular hire’s candidate history to a separate doc, and then clear sensitive info in the original doc, or delete it entirely in the original doc. Or maintain a separate doc for HR hires, which also is not pretty.