Out of Box sn_hr_core_task permissions rationale

Andy Foster · ‎03-14-2022

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?

Susan Britt · ‎03-16-2022

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

Susan Britt · ‎04-26-2024

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

Community Alums · ‎03-15-2022

Hi @Andy Foster ,

When we given access to some HR agents with sn_hr_core_basic role that means we have already considered the sensitivity of Cases in our mind and confident that these group of people of HR Agents will be dealing with the cases as a BAU activity .

These HR agents are the only users in HR space who deals with HR cases and nobody else has any visibility.

Coming to on the basis of COE case management, so you can use COE security configuration.

OR you can create a custom role to deal with access with the help of ACLs too.

Mark my answer correct & Helpful, if Applicable.

Thanks,

Sandeep

John Zhang1 · ‎03-15-2022

HR case (sn_hr_core_case) is a parent of each HR COE, but HR task (sn_hr_core_task) is a child of task class (table) like all other tasks (sc_task, incident_task, problem_task and change_task). HR task is connected to HR case by its parent field (referenced to HR case table).

HR agent with a role -sn_hr_core_basic can read and write for both HR case and HR task because sn_hr_core_basic contains a role sn_hr_core.case_writer. A role sn_hr_core.case_writer has been used within ACLs (write access) of both HR case and HR task.

The COE Security configuration (policies) is only used to control across COE HR case access, but not for HR task, which is secured by ACLs. HR task is belonged to each type of COE case. They can access each other data via a parent reference filed of HR task.

You can keep the sensitive data on either HR case and HR task. For the sensitive data access, you may need to define any additional security controls based on the user requirement.

Let me know if you have any additional questions.

If my reply is Helpful/Correct, please mark the answer as Helpful/Correct.

Susan Britt · ‎03-16-2022

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.

Kushan · ‎04-25-2024

I agree on this. So even in case we want to restrict child tasks similar to the security policies applied on the case tables, we would not be able to achieve this via COE Security policies and we may have to have a separate rule or ACL's to apply restrictions on tasks is it?