Employee Document Management Insights and Guidance

[nickdonatelli]

Avoid customizing UI pages for document upload/edit/view and move attachments

This is a large effort customization which will need to be maintained on an ongoing basis (troubleshooting/diagnostics, regression testing post-upgrade, etc.).

Avoid making document types holistically too granular or too broad

The former creates unnecessary administrative burden and is a hassle to maintain without giving a ton of added benefit. While more specificity in document types does give the added benefit of improved searchability, security and retention policies will need to be created and maintained for each document type. Depending on the size of your company, this can become a burdensome task relatively quickly.

The challenge that the latter approach creates is two-fold. First, OOTB the EDM doesn’t enforce any file naming conventions, so a more general structure (absent an iron-clad data governance process and 100 percent adherence to it by the people managing these documents which is very unlikely at scale) is probably going to result in multiple different documents (for instance a resume, NDA, offer letter, other agreements, I9, etc.) all being associated to a given document type but being indistinguishable from one another for someone looking to view those documents.

The other challenge that this poses is that in order to create distinctions between different documents under a broad document type, you likely need to add other fields to the Employee Documents table.  That in itself is easy enough, however, adding those fields to display anywhere beyond the list view of the application entails some heavy-duty customization because of how the document upload/document move/document view pages are designed. The end result is you either pursue a customization and all that that entails (see no. 1 above) or endure a suboptimal experience whereby fulfillers create/upload a document record, then need to remember to go back to the list view and find the document to add the other information, or those fulfillers need to manually rename files to fit a predefined naming convention.

Another crucial consideration in this decision which may mitigate some of the risk and pain of the above is how you expect to receive/upload documents. Will the majority of documents be generated automatically in ServiceNow or via integration with a third party system where a naming convention could be expected to be reasonably consistent and well thought out? If so, then the 'folder' approach might be more suitable. If the bulk of documents to be generated are coming from non-automated casework submissions, email attachments to be uploaded, or any other method in which inconsistent naming conventions cannot be avoided, there is much greater risk in taking the 'folder' approach. More often than not, companies are receiving documents from a constellation of sources, and consistent document naming cannot be guaranteed.

Nonetheless, best practice is still to have a well-defined file naming convention that is consistently applied and which communicates what the document itself specifically is, but also it is crucial establish Document Types in EDM that provide the right level of specificity required. This typically means taking a hybrid approach, where general and specific Document Types are situation-dependent. Have one document type per unique document you have (not necessarily down to the different version by year though) where necessary and use more generic document types when you can or when the situation dictates (such as a transcript). With this approach a list of documents types might look as follows:

I9

Non-disclosure agreement

Non-compete agreement

Covid testing/vaccine policy acknowledgment

Transcripts

Tuition Receipts

Disciplinary Notices

Performance Improvement Plan

Company-specific intellectual property agreement

Etc.

Security Policies can get elaborate quickly - work with stakeholders to define the right level of security

Large multinationals often need the ability to grant read-only access to users in a very granular way (i.e. read only access to documents for employees in a specific German works council visible only to EDM users in a particular group) so these circumstances need to be accounted for, but defining security policies is the right time to consider whether the administrative burden of creating and maintaining security policies can be lessened by (1) evaluating whether very small, niche audiences truly need EDM access at all or if there's an opportunity to create a formal request channel for specific employee documents via an HR service request and/or (2) if security can be structured more broadly on balance while making smaller, more granular policies to account for the outliers. As a general rule, granting EDM read/write access to fewer people and opening a formal request channel for accessing employee documents allows for the creation of less onerous security structure so it's recommended to work with the appropriate stakeholders in legal/compliance/privacy/leadership within an organization to determine if such a strategy can be pursued.