Highlights

• Automatic extendable security for even dynamically created lists and customized applications on Skelta BPM.NET platform.
• Collaborate effectively during workflow creation
• Define user-based access rights for workflow design functions
• Leverage in-built workflows to collaborate during process and form design
• Define security at item, folder and other levels
• Comprehensive security for reporting and BAM
• Use SharePoint Users to define security inside Skelta Enterprise Console
• Use Skelta’s external user repository architecture for defining users and roles
• Manage itemized rights including Add, Delete, Edit, Publish, Enable, Version Creation, View Others draft, Pending, Folder, and Owned Items

Click to Enlarge

Business Scenario

Company X's HR department maintains employee appraisal lists for evaluations. It is critical that the information maintained therein be visible only to senior members of the HR department and department heads conducting these evaluations. Further, the company also requires secure workflow transactions especially for the HR and Finance team in order to avoid cross access between the departments and ensure secure information flow for sensitive data.

The company needs a solution, which can provide a secure collaborative platform for its knowledge workers across the organization and which allows rights of access to be clearly defined based on roles and designations.

Skelta BPM.NET’s enhanced security features provided the answer. With extendable security that also covers created lists, employee appraisal information can be made accessible only to designated users. Further the system can effectively collaborate during workflow creation, process and form design, and define user-based access rights for workflow design functions. This will ensure ‘tamper proof’ workflow design for the company’s HR and Finance departments.

Skelta BPM.NET’s security features can also define security at the item level or folder level. It also offers comprehensive security for reporting & BAM.

Initially, all employees can be assigned ‘limited access’ rights.

As an example, consider the situation where the Administrator defines the access rights. Suppose a CEO is assigned Administrator rights, then the CEO can perform all the actions, just like an administrator. In turn, the CEO can also assign rights to his subordinates.

At the next lower level, say Managers, Contributor rights can be assigned, wherein the Managers can have rights one rung below the administrator. Even at this level, a particular Manager can be assigned Administrator rights.

Click to Enlarge

At the next lower level, Limited Access rights can be assigned, wherein only the Inbox can be viewed. Further one level below, Reader rights can be assigned. A Reader can view all the features, but cannot perform any actions – like edit, delete, etc.

So, depending on the designation of the employee, access rights can be defined.