Hi there,
Couldn't seem to find info on the multiple roles and their associated views and/or privileges in Jobscore.
Would be great to have an entry on the FAQ that gives a breakdown for each role (interviewer vs. hiring manager vs. recruiter, etc)
We'd like to know the best way to share candidates with team members without sharing too much info/job details/etc with the employee population. Assume 'Interviewer' has the least privileges, but wasn't 100% sure.
Thx++
Nick
Hi Nick,
Great idea. Currently there are no rules associated with Hiring Team roles in the system, but we are about to add some restrictions to access to NOTES in the system based on the hiring team role. So here's how it would work:
Notes that are marked private can only be read by the person who created them. Period.
People with type = admin can read all non-private notes in the system. (as it works right now)
People with type = user will have note visibility restricted based on their roles on specific hiring teams. By default they will be able to read all of their own notes (as it works right now), but we'll make the following change:
If someone is type=USER is on the hiring team for a job with the role of Recruiter, Hiring Manager or Human Resources, they will be able to access all of the non-private notes for users assigned to that specific job. In effect this means that they'll have "ADMIN" like visibility, but only for specific jobs.
Please let me know what you think of this change and if it would better meet your needs.
And, of course, once updated we'll update the copy here in our support forums.
We also need this.
How can we:
) make sure that USERs only see aplications for jobs they are on a hiring team?
) assign only selected application for a given USER to handle, irrespective if he has hiring role for a job?
Right now we are considering enabling Google Apps access, but if I understand correctly that would make everyone, even just hired, automatically a USER with rights to browse every application (minus the notes)... not cool.
Hi Bart, (just guessing)
JobScore is specifically designed so that every employee can find every resume / applicant in the system.
We do have permissions controls over notes appended to their records (which certainly are sensitive -and we are trying to make this even better...), but the actual resumes and job application history is accessible by everyone.
The user interface is designed to direct people to only the information they need to see (based on job assignments that you control) - but if you want to look up someone's information you can.
Are you saying that you want granular control on a user-by-user basis of who has access to which individual job and record in the system?
Hi, thanks for prompt reply:)
Of course we don't want every employee to have access to every application - besides business reasons, there are legal ones, including protection of sensitive personal data. Only authorized employees can process applications, not just a random intern. Some applications are sensitive just for the fact that they were sent (e.g. from competitors).
Right now we simply only grant access to JS to people who have full rights to all applications anyway. It works even though makes impossible for other employees to help with just specific jobs/applications.
On the other hand if we switched to Google Apps login, which I was referring to, then if I understand correctly it would automatically grant full access to every user (some of which might not even be employees with NDA signed).
It seemed fair to expect that read access to application is conditional at least on having any kind of role with regards to particular job.
Yes, you are correct - google apps will allow anyone on your domain to access jobscore through the universal navigation. AFAIK this is simply how google apps (marketplace) works - if you'd like an alternate implementation, kindly take it up with them.
The solution you've chosen (only allow users who should see everything into your account) seems appropriate for your organization.
We are going to circle the wagons on your concern later this week and see what we can do. This would be a dramatic change to how JobScore works and we'd likely need to turn off a HUGE percentage of functionality to accommodate your enhancement request - it would likely be quite some time before any changes are in production - just want to be straight with you on that.
Could you please point me at the legislation you are concerned with? This data is protected behind password protection.
Sensitive applications - what, specifically are you concerned with - that your employees will leak information?
Thinking about this some more - is this what you would like:
Remove all search and autocomplete functionality from the main navigation (meaning users could only find and click into candidates records from the pipeline report on the homepage) - you couldn't just "look up a record"
Remove the filtering capability from the candidate manager, only showing candidates for the jobs the user was assigned to.
Remove the filtering capability from the job manager, only showing a list of open jobs. Remove the "expando" functionality from the job manager so users can't see the candidate pipeline (to see candidates they "aren't supposed to")
Don't let users click on job records at all (which have clickable pipeline reports and many other edit links)
5, Don't let users click on their own records and adjust their job assignments, role or email alert preferences (because it would give them access to candidates they aren't supposed to see)
Turn of de-duplication when adding resumes because you might find out that the company spoke with a candidate from a competitor before...
Etc, etc.
The idea would be to create a version of jobscore where users could only see candidates assigned to jobs where they are on the "hiring team", clicking on them to view resumes, add notes and (as appropriate) read notes - and that's it.
It would require recruiters and hiring managers (admins) to be extremely dilligent about building hiring teams to ensure the right people could access information when they need it. It would also mean people are constantly asking admins to change stuff in jobscore for them so they can find resumes, add notes, etc.
It would also mean that people couldn't see their own referrals (if you referred someone for a job that you weren't on the hiring team for, they wouldn't show up)
In short, if you try to start creating user based access control it makes jobscore less useful and creates administrative overhead for others in the company... and we'd end up having to redesign several aspects of the system to accommodate this... if this is in fact the desire of the community, we are up for it, but the need would have to be overwhelming for us to prioritize this...
Hey, you are right that this is to some extent limitation to Google Apps, since it is not possible to limit app to a subset of users.
I can see atomic access could be complex and I don't even know if other ATS have it; but maybe you can do something about Google Apps login on your side - can't imagine any organization larger that 5 people would want everyone in the domain to have access to all incoming apps.
And having one login less to manage is a huge plus.
Legislation is country-specific - here there are requirements to take proper care for databases with personal details to be well protected, including through access rights.
PS. for example, create third user type (guest?) with no access rights to anything, and map all new google apps users to this type by default, then admins would promote the HR people to users or admins.
Hi Bart,
Extension of permissions isn't a trivial enhancement. If a person joined given the scenario I outlined above they wouldn't be assigned to any jobs when they joined - hence, they literally wouldn't be able to do _anything _other than make referrals until an admin put them on the hiring team for a few jobs.
Is this what you want?
dan
Not exactly, not sure if you read the last update - keep the current system as it is (i.e no access dependability on being assigned to jobs), just add access-less default user type (apart from user and admin) for google apps users. Sure they wouldn't be able to do (almost) anything before being promoted to user, but after that all would be as it is now.
Unless there is a simpler way not to grant all GA users access rights.
I just submitted a similar request (sorry for the dup but I didn't see this request first). Dan's outline of changes seems correct. My basic idea is to limit access to data based on their hiring team assignments, i.e., a user is only allowed to see the jobs and in turn the candidates, notes, email, applications, etc. they are assigned to. In most cases this is just for people involved in the interviewing/screening process so my idea below might be much easier to meet this objective in the short term ...
I submitted another request that might be easier in the short term and come close to meeting these needs - i.e., allow a hiring team member to forward a candidate to a non-user. This would simply allow somebody to forward the resume with a cover note to somebody not a user and ask for their feedback (and the email template would not include the links to access the system). This could be somebody within the company or outside (e.g., a board member, client, etc.). In the future, the system could allow them to respond via email and record their response in the Notes but in the short term the individual forwarding the candidate could simply copy and past any email response into notes after they get a response.
Hi Michael,
We ended up implementing exactly what you've suggested here. you can now add users to jobscore without sending them an invite (meaning they can't actually log in to the employer facing web ui)
however, you can send them email and, more importantly, they can respond to those emails and with our email tracking feature the responses are recorded in jobscore.
more detail on how email tracking works is here:
This seems like a pretty solid workaround which a few customers are now testing... and we may productize this as "guest access" moving forward.
Hi All - would like to jump on the bandwagon and just request a list in the FAQ somewhere that just defines each role and what each one can do (having difficulty determining which roles to assign and have had to use some trial and error to figure out what each role can actually do).
We have resolved to updating our access levels. This has been in beta for a while and we anticipate launching it to everyone this week. The requested HelpCenter Summary for Access Levels can be found here
Happy Hiring!
Dan
