Implementation Guide for Employee Records Management (ERM)

About

This implementation guide outlines the essential steps for a successful implementation of the Employee Records Management (ERM) solution powered by VisualVault.

Who should use this guide? This guide is intended for implementation teams and project managers involved in configuring and deploying the ERM solution.

Who benefits from following this guide? All VisualVault departments benefit by being able to quickly and efficiently deploy the ERM solution for customers. Technical Support agents may also use this guide to understand the context of how the solution was implemented.

When should this guide be used? Use this guide during the initial setup and configuration phase of the ERM implementation.

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 correctly configured before rollout.

Why is this guide necessary? This guide ensures consistency and accuracy throughout the implementation process, reducing the risk of errors and delays, and helping your organization maximize the value of the ERM solution from day one.

Why should departments follow the checklist? Following the checklist ensures that all technical and functional requirements are met, resulting in a seamless ERM solution deployment for clients.

Key Concepts

What is a Database Template?

A database template is a parameterized, customer-neutral configuration baseline of the core product that is safe to reuse as a starting point for another customer. It excludes or anonymizes customer data and contains migration scripts to align with the latest Platform/Feature versions. System Administrators are responsible and accountable for the source database.

• Empty State: The database template excludes or anonymizes customer data, providing a blank slate for new projects.

• Predefined Schema and Structure: Standard configurations are built in and ready to use.

What is a Clone Database?

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

• 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 Dynamic 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.

• 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.

🔍 Troubleshooting Note: If a customer requests features or configurations that fall outside the vertical market solution scope, do not attempt to accommodate the request independently. Escalate to the Product team before making any changes.

Implementation Guide

Getting Started

🔧 Implementor Checklist

• Submit Change Control Form (CCF) with a support ticket and request System Administrator clone the database template for ERM.

• Verify that the clone database accurately reflects all database template features before beginning configurations.

• Document and report any discrepancies to the System Administrator before proceeding.

Predefined Features

Document Library Structure

The ERM solution uses a 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

🔧 Implementor Checklist

• Verify that the folder hierarchy is created as specified above. Deviations from this structure may cause routing and automation failures.

• Do not create, modify, or delete folder structure. Report any discrepancies to the System Administrator.

Important Notice: The Document Library structure will be reorganized and improved in ERM v2.1 (scheduled release date April 2026).

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

   • Required

   • Type: Text Box

2. Index Field Name: Last Name

   • Required

   • Type: Text Box

3. Index Field Name: Employee Unique Identifier

   • Required

   • Type: Numeric

4. Index Field Name: Document Type

   • Required

   • Type: Drop Down List

🔧 Implementor Checklist

• Verify all index fields are present. Verify field names, types, and required settings match the specifications above. Verify index fields are copied to all subfolders.

• Do not create, modify, or delete any index fields. Report any discrepancies to the System Administrator.

🔍 Troubleshooting Note: 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.

🔧 Implementor Checklist

• Verify the folder view includes all standard document index fields and the four (4) custom index fields.

• Do not create, modify, or delete any folder views. Report any discrepancies to the System Administrator.

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].

🔧 Implementor Checklist

• Verify each dashboard filter returns the correct employee set and the element security settings.

• Do not create, modify, or delete any form data dashboards. Report any discrepancies to the System Administrator.

🔍 Troubleshooting Note: If a dashboard appears empty, first verify that the EmploymentStatus filter value exactly matches the data values in the Employee Master iForm (e.g., Active vs. active). Filter values are case-sensitive.

Landing Page

The landing page is the first screen that users see when logging in to VisualVault. Use menu items to set the landing page to be the ERM application.

• Menu item(s)

  1. Add Menu: [menuName]

     1. 

  2. Edit Menu Properties

     1. Select Custom URL from the Action dropdown list. Enter the full URL in the text field.

        

  3. Add Element security [parentName/childName]

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

🔧 Implementor Checklist

• Add menu item and configure the URL. Ensure that the full URL is correct.

• Enable Append Access Token in menu node properties.

• Add element security to the menu item.

• Confirm with the customer which user groups require ERM as their landing page.

Employee Search

The Employee Search application feature provides role-based, limited access to employee data through a secure search interface. This eliminates the need for the user to directly access the Document Library. Learn more about the technical architecture and how to configure Employee Search.

🔧 Implementor Checklist

• Ensure the Okta-Workflow List of Managers group exists in Okta and contains the appropriate managers.

• Map this group to the corresponding VisualVault security group to enforce search result scoping.

Audits

Audit processes can be optimized by implementing a single search screen to locate and select employee records efficiently. This application eliminates the need for navigating multiple folders, reduce search times, and ensure accuracy by consolidating data access into a unified interface. Learn more about the technical architecture and how to configure Audits.

🔧 Implementor Checklist

• Configure the client and server variables in /Services/configvariables.js and /Services/serverstrings.js

• Define custom SQL queries in VisualVault Control Panel under Enterprise Tools → Data Connections

• Deploy application code with configured environment variables

• Verify application is accessible from the VisualVault landing page

HR Automation, Folder Creation/Updates

The HR Automation feature streamlines the management of employee records by automatically creating and maintaining Document Library folders in response to changes in the Employee Master Form. Learn more about the technical architecture and how to configure HR Automation.

🔧 Implementor Checklist

• Verify that security groups created in VisualVault match the Security Matrix.

• Verify security groups were populated with appropriate users.

• Configure the sFTP server with credentials and remote path matching App.config FTP settings.

Dynamic Features

Single Sign-On (SSO)

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.

🔧 Implementor Checklist

• 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).

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

• 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.

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

• 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.

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

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

Employee Master iForm

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]

🔧 Implementor Checklist

• Start from the base Employee Master Form template. Do not use a custom or modified template.

• Add required custom fields only. Confirm total field count does not exceed 20, including hidden predefined fields. Follow established naming conventions for all custom fields.

• Configure dropdown control: enable query, set query name, adjust control size, and set Data Lookup Property to Value Property.

• Update font to Source Sans Pro, size 11 for all labels and fields.

• Update group names and visibility/read only conditions.

• Apply client-side scripts. Document commit IDs and descriptions.

• Confirm all predefined fields are intact, including hidden fields.

Important Notice: The Employee Master iForm will be replaced with a database table in ERM v2.1 (scheduled release date April 2026).

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.

🔧 Implementor Checklist:

• Review predefined User Groups — confirm all groups have been inherited correctly from the source database

• Assign all users to the appropriate User Group — audit assignments with the client before go-live

• Verify permissions and security settings are consistent with the source database