How to Run a DMS Proof of Concept: Test Scenarios and Acceptance Criteria

Ask someone in procurement to find the latest agreement with a supplier. Give them the supplier’s name, but leave out the filename. Then ask a colleague from another department to try opening a confidential document they should not be able to access.

These are useful starting points for a DMS proof of concept. They tell you how document management software handles the work your organization needs to get right every day.

A good evaluation should leave you with evidence: which documents people found, which actions the system blocked, where approvals went, and how much help users needed. This guide sets out test scenarios and acceptance criteria for permissions, search, workflows, adoption, and representative workloads. You can use it to structure a Folderit evaluation and compare the results with other shortlisted vendors.

What is a DMS proof of concept?

A document management system proof of concept is a limited evaluation using your document samples, user roles, and business processes. Its purpose is to establish whether the proposed system can meet your requirements before you commit to a wider rollout.

A demonstration introduces the product. During a proof of concept, your team performs agreed tasks and records the results. A pilot can follow, with a department using the configured system over a longer period to assess day-to-day operation.

For procurement, the most useful output is a test record that connects each requirement to an observed result and a decision.

Agree on the scope before opening the trial

Choose two or three processes that will be part of your first rollout. Supplier agreements, invoice approvals, and policy distribution make a practical combination: they involve different documents, permissions, and decisions.

Write a short evaluation brief covering:

• People: the business owner, IT administrator, security reviewer, procurement lead, and employees who will perform the tests.
• Configuration: the proposed plan, deployment, identity setup, integrations, and features enabled for the evaluation.
• Documents: the formats, languages, sizes, folder structures, and metadata you will use.
• Workload: expected daily uploads, busiest periods, active users, and initial migration volume.
• Decision: mandatory tests, acceptable thresholds, evidence required, and who signs off.

Agree on the thresholds before testing starts. If a requirement changes, record why and apply the revised test consistently to each vendor.

When evaluating Folderit, check that the trial configuration matches the proposed subscription. Its Tailor plan includes granular permissions, Workflow Designer, SSO, and API access. Confirm the users, storage, and integrations needed for your particular evaluation.

Build a document sample that resembles your working files

Take samples from the departments involved in the first rollout. Include scanned agreements, ordinary PDFs, Office documents, email attachments, and the occasional awkward file that your team still needs to manage. Use approved or anonymized copies.

Keep the proportions close to reality. If half your incoming documents are scans, make scans a substantial part of the test. Include the languages you use, your larger files, similar filenames, older versions, and documents with incomplete metadata.

Prepare a manifest before importing anything. Record each file’s identifier, expected folder, size, key metadata, and permitted users. For search tests, add the query you will run and the document you expect to find.

A set of 1,000 documents and 10 participants can be a starting example for a focused evaluation. Your workload test may need a larger repository or more active users. Choose those numbers from your expected usage and agree the test conditions with the vendor.

DMS test scenarios and acceptance criteria

The numerical targets below are examples to adapt before the evaluation. They are buyer acceptance criteria, not published Folderit performance guarantees.

1. Permissions: check both allowed and blocked actions

Create separate accounts for a document owner, a department employee, a preview-only reviewer, and someone with no access to the test folder. Write down what each person should be able to see, download, change, and share.

Run the test while signed in as each user. An administrator’s view cannot establish what a restricted user can do.

1. Give the reviewer preview-only access to a supported document. Try previewing, downloading, printing through the application, changing metadata, and uploading a new version.
2. Use the account with no access to search for the document by name and by a distinctive phrase. Try opening its saved URL.
3. Check access received through a group or parent folder as well as direct sharing. Remove every applicable grant for one test user, refresh the session, and repeat the access attempts.
4. Ask the authorized employee to complete the actions their role requires. Confirm that restrictions have not prevented legitimate work.

Acceptance criteria: Every allowed and blocked action matches the agreed permission matrix. An unauthorized account sees no protected document content or metadata in the tested views. Access removal takes effect within the interval agreed before the test.

Folderit’s permission levels include Previewer, Viewer, Editor, Upload-only, and Custom. Previewer supports in-system review without application download or print access. Custom permissions let you configure individual actions when a standard level is too broad.

2. Search: find documents without knowing their filenames

Ask employees for questions they regularly need to answer: “Where is the maintenance agreement for this site?” or “Which supplier sent this invoice?” Use those questions to build 20 search tasks with known answers.

Include a mix of filename searches, metadata filters, and phrases found only inside documents. Put some of those phrases in scans. Include similar documents so the evaluator has to identify the correct result.

1. Import the sample and record when it becomes searchable. Measure this indexing delay separately from the time taken to return a query.
2. Run each query as a user who should have access. Record whether they find the expected document and how long it takes to open it.
3. Repeat selected queries as a restricted user to check that search respects permissions.
4. Investigate misses by file type, scan quality, language, and search settings. Keep the original results when you retest.

Example acceptance criteria: Users find the correct document within 60 seconds in at least 18 of the 20 tasks. Every task marked business-critical passes. Restricted documents remain hidden from unauthorized users.

Folderit offers Live Search, Deep Search, and metadata filters. Use Deep Search when testing document contents. It supports content search in formats including PDF and DOCX, plus text in PNG and JPG images; XLSX content is not included in OCR content search. Set the appropriate OCR language for your samples.

3. Workflows: follow an approval through to the evidence

Choose a process with a clear owner. For example, a supplier agreement might need procurement approval followed by a finance decision before it moves to an approved folder.

Prepare three copies of the test document: one to approve, one to reject, and one to leave pending. Agree on the expected outcome for each.

1. Submit the first document through the planned intake route. Check that the workflow starts and reaches the right recipient.
2. Complete the serial approval. Confirm that the second approver receives their task at the correct point and that the document reaches the configured destination.
3. Reject the second document. Check the recorded decision and the configured failure outcome. It must not appear as approved.
4. Leave the third document pending. Confirm that the process owner can identify the outstanding task. If timeout handling is in scope, test its configured outcome.
5. Have your own administrator change an approver and run a fresh instance. Record the help and time needed.

Acceptance criteria: Each test follows its agreed route, with the correct recipients and final status. Pending work remains visible. The evaluator can retrieve the decisions and related document activity without relying on the vendor to explain what happened.

Folderit supports serial, parallel, and staged approvals, reusable templates, and folder-triggered workflows. Its Workflow Designer supports separate success, failure, and timeout paths. Configure the routes your process needs before running the test.

Also inspect the document audit trail. Match a known preview, metadata change, and access change to the recorded user, event, and time. Keep workflow decisions and document activity together in the evidence record.

4. Adoption: let employees complete the work

Include people who will use the system occasionally as well as those who handle documents all day. Give everyone the same short introduction, then let them work through the tasks on their own.

For a 10-person group, assign four tasks to each participant, adjusted for their role:

• Find and open a specified document.
• Upload a file and complete its metadata, or perform another permitted document task.
• Complete an assigned approval or acknowledgement.
• Find an outstanding request or check the result of an earlier decision.

Record completion time, mistakes, and requests for help. Agree a time limit for each task in advance. Ask participants where they hesitated and what they expected to happen; those answers often reveal a folder naming or configuration issue you can fix before rollout.

Example acceptance criteria: At least 36 of the 40 task attempts are completed correctly, within their agreed time limits, without assistance after the introduction. Each role group achieves at least 80% independent completion. Any configuration changes are followed by a recorded retest.

In Folderit, include the personal dashboard in this exercise. It brings together assigned tasks, requests awaiting action from others, and decision history. Have employees use it to find their next task and follow up on work they have sent.

5. Representative workloads: test a busy period

Build a workload from what your departments actually do. During an invoice run, some people will upload documents while others search, preview files, and approve requests. Test those activities together.

For example, run a 30-minute session with 10 active users against the agreed document sample. Have some participants search and preview while others upload a batch of 100 representative files and complete workflow tasks. Adjust the repository size, file mix, activity rate, and concurrency to match your expected busy period.

Record the browser, network location, file sizes, active-user count, and number of attempts for each operation. Measure:

• Search response: time from submitting a query to receiving usable results.
• Preview time: time from requesting a preview to being able to read it.
• Upload completion: time until the file has finished transferring.
• Indexing delay: time until newly uploaded content can be found through the agreed search.
• Accuracy: missing files, unexplained duplicates, metadata errors, and incorrect workflow outcomes.

Example acceptance criteria: At least 95% of measured searches return within three seconds, and at least 95% of previews open within five seconds for the agreed file mix. Every source file is accounted for, with no unexplained loss or duplication. Upload and indexing times meet the separate thresholds agreed for that batch. Record failed operations separately; do not remove them from the results.

Folderit provides several import routes, including browser uploads, email, API, and sFTP. Test the route you intend to use. If the initial migration requires a different method from daily intake, give it a separate test and reconcile its results against the source manifest.

A successful session establishes what happened under those conditions. If your rollout involves substantially more documents or concurrent users, arrange a larger test with the vendor before drawing a capacity conclusion.

Copy this DMS proof-of-concept acceptance checklist

Use these rows in your evaluation record. Add an owner, actual result, evidence link, and status to each one. Keep the agreed thresholds beside the results so the selection team can see exactly what passed.

Set a timetable and make the decision

For a focused evaluation, you could reserve two working weeks: two days for setup and sample import, three for permissions, search, and workflows, two for employee tasks, one for the workload session, and two for retesting and review. Add time where identity setup, integrations, or migration preparation require it.

Use four statuses: Pass, Fail, Blocked, and Not tested. A blocked or untested requirement still needs evidence. When a test fails, record whether the cause is configuration, source data, training, an integration dependency, or a product gap. Assign an owner and a retest date.

Move to the next stage when mandatory tests have passed and the business owner has accepted any remaining minor issues with named owners and deadlines. A high average score should never cancel out a failed mandatory access-control test.

Keep the final configuration, evidence, outstanding actions, and required subscription together. That record gives the implementation team an agreed starting point and helps procurement check that the proposal covers what was evaluated.

DMS proof of concept FAQs

How many documents should a DMS proof of concept include?

Include enough to cover your important file types, languages, sizes, access rules, and workflows. Use a defined sample for functional tests, then size the workload test around expected repository volume and concurrent activity. A small functional sample cannot establish performance at a much larger scale.

Who should take part in a DMS evaluation?

Include the business owner, IT, a security reviewer, procurement, and employees from the departments in scope. Business users assess everyday tasks; administrators assess configuration and maintenance; procurement records the evidence and checks the proposed costs.

What are the most important DMS acceptance criteria?

Start with correct access permissions, reliable retrieval, accurate workflow routing, traceable activity, successful employee tasks, and complete document imports. Add measurable workload targets that reflect your planned use.

Can we use these scenarios to evaluate Folderit?

Yes. These scenarios cover document controls and working processes supported by Folderit. Agree on the plan, configuration, sample data, and acceptance thresholds with the team, then have your own evaluators perform the tasks and record the results.

Plan your Folderit proof of concept

Bring the documents people struggle to find, the approval that regularly gets stuck, and the access rules your administrators have to maintain. Those examples give a Folderit evaluation a clear purpose.

Contact Folderit to discuss your proof of concept. Share your first three processes, expected users and document volumes, and the tests you need to pass. Ask the team to help define a configuration your employees can put to work and your procurement team can assess.