Workslayr’s Module Access Control allows you to define which core modules and functionalities are visible and accessible to different user roles within your organization. This granular control is crucial for maintaining data security, ensuring employees only see relevant information, and streamlining their Workslayr experience by removing unnecessary distractions.
Every employee in Workslayr is assigned a specific role, which dictates their default permissions. Module Access Control builds on this foundation by enabling administrators to toggle entire modules on or off for specific roles. For instance, you might want your project managers to have full access to the Projects module, but only view access to the Clients module, and no access to the HR module.
How Module Access Control Works #
Module Access Control operates at a high level, determining whether a user role can see and interact with a module at all. If a module is disabled for a role, all its associated sub-features, data, and settings become inaccessible to users with that role. If a module is enabled, then more specific permissions, such as View, Edit, or Delete permissions, can be configured for individual elements within that module.
For example, if you disable the Leads module for a specific employee role, users with this role will not see the “Leads” tab in their main navigation. Consequently, they won’t be able to access Lead Contact details, create new leads, or manage deals. This is particularly useful for roles that do not require sales-related functionalities, helping them focus on their primary tasks.
Configuring Module Access #
Administrators can adjust module access settings by navigating to ‘Settings’ and then to ‘Module Settings’. Here, you’ll find a list of all available Workslayr modules. For each module, you can specify whether it’s enabled for ‘Admin’ roles and ‘Employee’ roles. Toggling a module off for a general category like ‘Employee’ will hide it from all default employee roles. Deeper control is available when creating custom roles, where you can individually configure module access for each custom role.
Understanding and carefully setting up Module Access Control is vital for maintaining a secure and efficient Workslayr environment tailored to your business operations. It ensures that sensitive data is protected and that employees can navigate the platform effectively, focusing on the tools most relevant to their responsibilities.
Within Workslayr, Feature-Level Permissions offer a granular approach to controlling access and actions for specific functionalities within a module. While Module Access Control determines if a user can access an entire module (like Employees or Projects), Feature-Level Permissions allow you to define precisely what actions users can perform within that module, making your operational workflows robust and secure.
This level of detail means you can tailor roles to perfectly match an employee’s responsibilities, preventing unauthorized actions or accidental data changes. For example, an employee might have access to the Projects module but only have permission to view project details, not edit them or create new ones. This structure is essential for maintaining data integrity and streamlining responsibilities across your team.
Understanding Feature-Level Access #
Workslayr’s Feature-Level Permissions extend beyond simple enable/disable toggles. They are often categorized by the type of action an employee can take, commonly including View, Edit, or Delete. This applies to various entities within Workslayr, whether it is managing clients, handling leads, or processing invoices.
Consider the Clients module. You might have a sales team member who needs to view all client profiles and contact information, but only a finance administrator should have the ability to edit billing details or delete a client record. Feature-Level Permissions allow you to configure these specific access rights. If a user tries to perform an action for which they lack permission, Workslayr will prevent the action, often displaying an “Access Denied” message.
Configuring Feature-Level Permissions #
When you are creating custom roles or modifying default roles, Workslayr provides a detailed list of features within each module. For each feature, you can grant or restrict access. This includes specific actions like:
- Viewing employee profiles: Grant to HR and managers.
- Editing employee leave requests: Restrict to HR and designated leave approvers.
- Creating new projects: Grant to project managers and administrators.
- Deleting project tasks: Restrict to project managers or team leads only.
- Accessing expense reports: Grant view access to managers, and edit/approve access to finance personnel.
Each of these granular settings ensures that your team members have exactly the tools and access they need to perform their duties without overextending their privileges. Remember, these permissions are typically defined at the role level, but Workslayr also offers Employee Permission Overrides for unique, individual adjustments.
Workslayr’s data visibility rules control which pieces of information users can access based on their assigned roles and specific permissions. This ensures employees only see data relevant to their responsibilities.
Visibility applies across various modules, impacting what a user can view, edit, or delete. These settings are part of module-level permissions.
Configuration #
Data visibility is configured during role creation or modification. For each module, you specify the scope of data access. This determines if a user can see:
- Only their own data (e.g., their My Dashboard, time logs, or submitted expenses).
- All data within their assigned department or team.
- All company data relevant to that module (e.g., all clients or projects).
For example, an employee might only be able to view their own projects, while a department manager could view all projects within their department. An administrator would typically have visibility into all projects company-wide. These settings work in conjunction with permission types like View, Edit, or Delete.
Individual employee settings can be adjusted using Employee Permission Overrides, which can grant or restrict access beyond the default role settings.
