User Permissions – Component Overview

 

Through this component you can define permissions for the service provider users.

The Service Provider Users can access the data of their client organizations by virtue of the relationships as defined in the ‘Component Interaction Model’. But among the Service Provider Users, there might be a need for security over and above the ‘Component Interaction Model’.  Through this activity, you can give user specific security to Component – Org. Units over and above the ‘Component Interaction Model’.

For example, a HR Manager could have access to data in all Employment Units. A HR Executive on the other hand could have access only to the Employment Unit to which he/she belongs. Such a need is fulfilled by Ramco Employee Induction. There is a facility to define permissions for User, Login Role and Login Org. Unit combinations. This combination is given permissions to specific Components – Org. Units.

User

Login Role

Login Org. Unit

Component

Org. Unit

HR Executive

HR User

New York

Employment Information

 New York

HR Manager

HR User

New York

Employment Information

 Boston

 New York

 Philadelphia

VP - HR

HR User

New York

Employment Information

 Boston

 New York

 Philadelphia

 San Francisco

 Los Angeles

 

 

You can set access permissions based on the login user-role-Org. Unit combinations. For a particular login user-role-Org. Unit combination, the components that would be listed in the left pane would be found from the deployment details . For all those Components, using the ‘Component Interaction Model’, the list of component-Org. Units where the same component is deployed and is interacting with the login component can be listed. Out of this list of Component –Org. Units the User-Role-Org. Unit combinations could be given permissions to the required Component-Org. Units.

Also, Ramco HRMS is designed to support a Business Process Outsourcing Organization (BPO) that carries out HRMS functions for its client organizations. A BPO user who has access rights to multiple organizations does not have to logout/login in order to switch from one client organization to another.

The User Permissions component aims at capturing and determining security access to different users and components from within a single login.

Consider the case of a service provider/ BPO, who has, in a single deployment, two independent enterprises with absolutely no interaction with each other.

In such a scenario, a user, regardless of the enterprise that he is interested in, would, in the Security Definitions component, be able to view all users created for that deployment. i.e. he would be able to view users created for the other enterprises also.

This component, Service provider Permissions, helps avoid this, and ensure that users in a particular security definitions component View and Access only users who are applicable and relevant to the login Org. Unit.

Here, the list of users applicable to each security definitions Organization Unit (Org. Unit) can be marked as such; only such users marked as applicable would now be fetched in Security Definitions.

The above would be applicable only in case of an interaction between the Security Definitions component and the User Permissions component. In its absence, all users created in deployment would be fetched.  A User Permissions component as the target could interact with multiple Security definition components as source. i.e. the interaction between User permissions and the Security Definitions component should be 1: n

As a service provider, a user would want to access details corresponding to different Org. Units without needing to log in separately to each Org. Unit. i.e. access should not be restricted to only details corresponding to the Login Org. Unit .

To support this, an ‘Org. Units’ combo is made available in applicable component activities, where the user can choose the org. unit he wants to work in.

The Org. Units–components that a user-role should have permissions to access from within a particular login Org – unit, are set in the User Permissions component. Such Org. Units that a user – role has permissions to from his login Org. Unit are then loaded in the Org. unit combo in the respective component-activities.