Out of Box sn_hr_core_task permissions rationale

Andy Foster
Tera Contributor

OOB the sn_hr_core_task table default form fields are generally accessible for read or write by users with the sn_hr_core_basic role, and not restricted based on the CoE of the Parent Case. 

Is there a specfic reason why it has been setup this way and if so does this mean information held in these tasks (ie worknotes and additional comments) should not really hold anything sensitive, and any sensitive information should only be held in the parent case type table fields?

2 ACCEPTED SOLUTIONS

Susan Britt
Mega Sage
Mega Sage

Hi Andy,

There are times in processes/services where one team (e.g., Tier 1) has access to the COE/HR Case, but the actual service (e.g., Employment Status change from full-time to part-time worker) process needs to have child HR Tasks for other teams (e.g., Benefits and Payroll).  You would not want the child HR Tasks security to be based on the parent HR Case.  

View solution in original post

Correct - COE security configuration is only for COE's (HR case tables).  To secure HR Tasks, you would need separate ACLs.  I would just think through the logic of current and future use cases of HR Tasks to make sure you are creating a bigger problem that will have to be unraveled later.  Obviously ER cases and tasks are different than the other COE tables (e.g., Payroll, Total Rewards).  One example or use case to think through, who would you lock down access to HR Task to knowing an HR Task doesn't have to be assigned to a group?  Would you want whoever has access to the parent HR Case to always have access (i.e., Opened For, Approvers, Assignment Group, all HR agents with sn_hr_core.basic role)? What if someone is added to the watch list of an HR Task, should they have access? Consider your normal use cases like this HR service automatically creates tasks for X department, but what about the one-off situations of the agent needing to add an ad-hoc task to the case?  What about bigger processes where leadership would want full visibility to all child tasks/steps like onboarding?

View solution in original post

5 REPLIES 5

Correct - COE security configuration is only for COE's (HR case tables).  To secure HR Tasks, you would need separate ACLs.  I would just think through the logic of current and future use cases of HR Tasks to make sure you are creating a bigger problem that will have to be unraveled later.  Obviously ER cases and tasks are different than the other COE tables (e.g., Payroll, Total Rewards).  One example or use case to think through, who would you lock down access to HR Task to knowing an HR Task doesn't have to be assigned to a group?  Would you want whoever has access to the parent HR Case to always have access (i.e., Opened For, Approvers, Assignment Group, all HR agents with sn_hr_core.basic role)? What if someone is added to the watch list of an HR Task, should they have access? Consider your normal use cases like this HR service automatically creates tasks for X department, but what about the one-off situations of the agent needing to add an ad-hoc task to the case?  What about bigger processes where leadership would want full visibility to all child tasks/steps like onboarding?