Implementation Guide for Employee Records Management (HR-1)

Prev Next
This content is currently unavailable in Spanish. You are viewing the default (English) version.

THIS ARTICLE IS UNDER CONSTRUCTION

About

The purpose of this guide is to provide a comprehensive outlines for the essential steps for a successful implementation of the VisualVault solution, Employee Records Management (HR-1).

Who should use this guide?

This implementation guide is intended for implementation teams and project managers involved in configuring and deploying the HR Level I solution.

Who benefits from following this guide?

All departments within VisualVault will benefit as they will be able to quickly and efficiently deploy and begin using the HR Level I solution for clients. Technical Support agents may also benefit from this guide to understand the context of how the solution was implemented.

When should this guide be used?

This guide should be used during the initial stages of implementing the HR Level I solution, specifically during the setup and configuration phase.

When is it most critical to follow the checklist?

It is most critical to follow the checklist during the pre-deployment phase, as it ensures all required components are in place and configured correctly for a successful rollout.

Why is this guide necessary?

This guide ensures consistency and accuracy during the implementation process, reducing the chances of errors and delays and helping the organization maximize the value of the HR Level I solution from day one.

Why should departments follow the checklist?

By following the checklist, departments will ensure they meet all technical and functional requirements, leading to a seamless HR Level I solution deployment for clients.

What is a Source Database?

A source database is a pre-configured database that serves as the blueprint and basis for creating new databases. It contains the standard structures (configurations, schemas, views, etc) that can be used as a starting point for new databases. System Administrators are responsible and accountable for the source database.

Key Features

  • Empty State: The source database will be empty (no data), which allows it to be used as a blank slate for new projects.

  • Predefined Schema and Structure

What is a Clone Database?

A clone database is a complete, exact copy of the source database. It replicates the structure, data, and configurations of the source database. Implementation teams are responsible and accountable for the clone database.


Implementation Guide

  1. Initiate a CCF and Support Ticket: Submit a Change Control Form (CCF) along with a support ticket to request the system administrator to clone the source database for Employee Records Management (HR-1).

  2. Configuration: When system admin gives access to the clone database, you will see that it has the predefined features ready. Make changes required to configure the dynamic features only.


Configuration Guidelines

  • Preserve Predefined Features: Ensure the “out-of-the-box” predefined features of the solution remain unchanged. The clone database should strictly maintain the current product features without modification.

  • Modify Only Dyanmic Features for Client Variables: Limit the changes to dynamic features to only configuring client variables. No other changes should be made to the clone database.

  • Limit Modifications: Refrain from adding new form templates, workflows, or making any modifications to the clone database. The feature set should remain as originally defined by the vertical market solution scope.

  • Reference best practices: Project Coding Standards

  • Consult Product Team for Additional Changes: If changes to features beyond the vertical market solution scope are required, immediately consult with the Product team to ensure these requests align with vertical market solution guidelines and standards.


Predefined Features

Ensure the “out-of-the-box” predefined features of the solution remain unchanged. The clone database should strictly maintain the current product features without modification.

Document Library Structure

  • Four-Level Document Library Structure

    • Level 1: Client - HR

      • Level 2: Active

        • Level 3: A

          • Level 4: Last name, First name, Unique ID

      • Level 2: Terminated

        • Level 3: A

          • Level 4: Last name, First name, Unique ID

Document Index Fields

  • Four custom Index Fields. Index fields are copied to all subfolders. Default Values are set from the Employee Master iForm data.

    1. Index Field Name: First Name

      1. Required

      2. Type: Text Box

    2. Index Field Name: Last Name

      1. Required

      2. Type: Text Box

    3. Index Field Name: Employee Unique Identifier

      1. Required

      2. Type: Numeric

    4. Index Field Name: Document Type

      1. Required

      2. Type: Drop Down List

    The new index field Document Type (which specifies W4, Nepotism, Notice, etc) must not conflict with default index field docType (which specifies PDF, TXT, etc).

Folder Views

  1. Create Folder View: Implement one (1) folder view for employee documents.

  2. Include Standard Document Index Fields: Ensure the view includes the standard document index fields.

  3. Include Custom Index Fields: Ensure the view includes the four (4) custom index fields.

VisualVault Dashboards

  1. Active Employees Dashboard: Display a list of all active employees.

    • Create a new Form Data Dashboard: Active Employees Dashboard

    • Add Columns [FirstName] [LastName] [DOB] [Department] [EmploymentStatus] [EmployeeID].

    • Add new filter: EmploymentStatus: Active

    • Add Element security: [groupName/userName] set as [viewer/editor/owner].

  2. Terminated Employees Dashboard: Display a list of all terminated employees.

    • Create a new Form Data Dashboard: Terminated Employees Dashboard

    • Add Columns [FirstName] [LastName] [DOB] [Department] [EmploymentStatus] [EmployeeID].

    • Add new filter: EmploymentStatus: Terminated

    • Add Element security: [groupName/userName] set as [viewer/editor/owner].

  3. All Employees Dashboard: Display a list of all employees.

    • Create a new Form Data Dashboard: All Employees Dashboard

    • Add Columns [FirstName] [LastName] [DOB] [Department] [EmploymentStatus] [EmployeeID].

    • Add new filter: N/A

    • Add Element security: [groupName/userName] set as [viewer/editor/owner].

Landing Page

  • Workspaces

    1. Create New Workspace: Landing Page

    2. Assign user group: [User/User Group] [userGroupName/userName]

    3. Screen layout set to: [One Column/Two Column]

    4. Add Tab content [tabName]

    5. Add Client Logo

    6. For Employee Search, add Module page viewer: [URL]

    7. For HR Survey / Employee Audits, add Module page viewer: [URL]

  • Menus

    1. Add Menu: [menuName]

    2. Add Element security [parentName/childName]

    3. [groupName/userName] set as [viewer/editor/owner]

Employee Search

  • CONTENT COMING SOON

HR Survey / Employee Audits

  • CONTENT COMING SOON

HR Automation, Folder Creation/Updates

  • CONTENT COMING SOON


Dynamic Features

Single Sign-On (SSO)

About: Single Sign-On (SSO) allows users to securely access the system using their existing organizational login credentials, streamlining the authentication process and reducing the need for multiple passwords.

  1. Gather Client’s IdP Information: Request the client’s Identity Provider (IdP) metadata (XML file or metadata URL) and confirm their IdP platform (e.g., Azure AD, Okta, Google Workspace).

  2. Provide Your SAML Details: Share your service provider’s (SP) metadata, including the Assertion Consumer Service (ACS) URL and Entity ID.

  3. Coordinate Attribute Mapping: Work with the client to ensure required attributes (e.g., email, firstName, lastName, userName, groupName, [viewer/editor/owner]) are included in the SAML assertion.

  4. Configure SSO on VisualVault’s End: Input the client’s IdP metadata into your SSO configuration settings and map the appropriate attributes.

  5. Test the Connection: Conduct end-to-end testing with the client to ensure users can authenticate successfully and land in the correct user role or group.

  6. Validate Roles and Permissions: Confirm that SSO users are correctly provisioned and authorized based on their assigned roles.

  7. At Go Live: Enable SSO for the client’s production users and provide onboarding or help documentation if needed.

Employee Master iForm

About: The Employee Master iForm is built from a standardized VV form template used for onboarding. When creating a customer-specific version, begin with the base template and add only the necessary custom fields. All custom fields must follow the established naming conventions and be renamed appropriately within the source database. Do not modify or remove any of the predefined fields included in the template, as they are essential to existing workflows and scheduled task automations. Several predefined fields may be hidden, but must remain intact to ensure proper functionality.

  1. Form Details (maximum of 20 fields)

    • Form Template Employee Master Form

    • Modify Form Name from [oldValue] to Employee Master Form.

    • Add [dropdownControlName] form control

    • Check Enable Query.

    • Set the query to [queryName].

    • Change the control size from [oldValue] to [newValue].

    • Set the Data Lookup Property to Value Property.

  2. Font

    • Update font sizes of labels and fields.

    • Font: set to Source Sans Pro.

    • Font size: set to 11.

  3. Groups And Conditions

    • Update [groupName].

    • Update [visibility/read only] conditions:

      • [fieldName] [is equal to/is not equal to/etc] '[value]'.

  4. Client-Side Scripts

    • [Commit ID 1] : [Commit Description]

    • [Commit ID 2] : [Commit Description]


User Groups and Permissions

Predefined User Groups: The source database defines User Groups with specific permissions, ensuring that the new database inherits the correct access controls.

Implementation teams should ensure that Users are added to the appropriate User Group.

Permissions/Security: The source database sets up access controls, including which User Groups have the ability to perform certain operations, to maintain consistent security within a clone database.

Area / Function

Survey Leader

Survey Coordinator

Compliance Team

Auditor

View Survey List Dashboard

✅ Editor

🚫 No Access

🔍 Viewer

🚫 No Access

Create a new survey

✅ Editor

🚫 No Access

🚫 No Access

🚫 No Access

Details Tab

✅ Editor

🚫 No Access

🔍 Viewer

🚫 No Access

Employees Tab

✅ Editor

🚫 No Access

🚫 No Access

🚫 No Access

Coordinator Screen

✅ Editor

✅ Editor

🚫 No Access

🚫 No Access

Documents Tab

✅ Editor

🚫 No Access

✅ Editor

🚫 No Access

Document Viewer

✅ Editor

🚫 No Access

✅ Editor

🚫 No Access


FAQ

“Why can’t I see any content?”

  • Common cause: The user set up with SSO may not have been assigned a Group.

  • Investigate:

    • Check that requester is a VaultAccess user, in order to comply with Security procedures.

    • Go to Central Admin > Users

    • Check Account Status: All Accounts

    • Search by the User ID

  • Fix: Enable user from Group Administration. (Note: if a user is disabled, then the client can not fix it themselves.)

    • Check User ID Never Expires

    • Check Password Never Expires

      • Known quirk: If the Password Expiration date is a past date then it will not allow login. First set this to year 9999 before you check box.

“Why can’t I find XYZ employee?”

  • Common cause: Using Employee Search, If a user enters their email address, then the result will display the employees who directly report to them in their organization. The user may need to have additional employee reports assigned to them in order to view the individual employee reports they are seeking.

  • Investigate:

    • Review the employee reports listed in the Employee Master Form and compare them with the number of result items to verify how many employees should be visible to this user.

    • VV personnel cannot grant access for users to view additional employee reports. If a request for such access is received, it should be redirected to the client’s internal ticketing system and approval process.

  • Fix: Redirect the user to the client’s internal ticketing system and approval process. Any escalation should be directed to the client’s VaultAdmin, who may approve the request and set the appropriate security permissions.

    • Users with VaultAdmin access within the organization can approve the necessary permissions and complete a Department Override Form to grant the required access to the user.