SharePoint Register Validation: A Worked Example of Field Settings and Tests

What you'll take away

A worked SharePoint quality-register design with column types, suggested settings and a pre-test checklist to adapt before moving beyond Excel. This article prepares the tests; the follow-up reviews the SharePoint results.

This article is part of the SharePoint quality-register validation series. It develops the field-design and pre-test stage of Validating a SharePoint Quality Register: A Worked Example. That guide covers the wider computerised system validation (CSV) approach; this instalment focuses on column settings and the tests planned to assess them.

For quality assurance (QA) and operations teams moving a quality register out of Excel, SharePoint Lists is an option to assess for GxP use. The work goes beyond data migration: field definitions, ownership and test evidence need to support the register's intended role in the quality process.

This guide provides a real-world example of some of the options you might use when configuring a SharePoint quality register. It uses a fictional deviation register to illustrate column types, required fields, unique identifiers, controlled choices, accountable owners and date rules, with a pre-test plan setting out the expected outcomes to check in SharePoint. The controlled deviation record remains authoritative; the list tracks its reference, owner, dates and status.

The practical output is a reviewable specification linking each proposed control to a test, so the process owner and list owner can agree what to build and what evidence to collect. A follow-up article will review the observed SharePoint results and any changes needed. This article covers preparation rather than execution; assess the wider GxP requirements for your intended use with the process owner.

1. Define the test setup and agree the rules

Agree the vocabulary, identifier format, date rules and responsibilities with the process owner. Assign a list owner with permission to manage columns, and use a separate test list with synthetic records. Assess changes to existing operational lists through change control: Microsoft notes that changing a column type can corrupt existing data.

For this example, agree these rules first:

• Each register row has one manually assigned identifier, such as DEV-2026-0001, unique within this list.
• Each row references an existing controlled deviation record. Multiple register rows may reference the same source record.
• Status is Open, In progress or Closed; classification is Minor, Major or Critical. These are illustrative labels, not regulatory definitions.
• Opened date, due date and one accountable person are required. Due date cannot precede opened date.
• Closure date is optional while work is open, but required when status is Closed. Any entered closure date cannot precede opened date.

Use the following column names exactly while following the example. Record the actual internal/API names separately if integrations use them: Microsoft Learn distinguishes a column's name from its user-facing displayName.

2. Specify the column types and settings

Use the following as the build specification for the test list when you are ready to configure it.

In the list, select + Add column, choose the type, enter its name and settings, then save. Use More options where shown. For additional types, Microsoft documents Add column > See all column types. To inspect an existing column, open Settings > List settings, then select it under Columns. Labels and available controls can differ between modern and classic screens; see Microsoft's column-creation instructions.

The Microsoft Learn references below describe SharePoint column properties through Microsoft Graph v1.0. You can apply the proposed settings through the list interface; API property names are included to help you trace each setting to its documentation.

Single line of text: summary, identifier and record reference

Use the existing Title column for a short summary; there is no need to create a second summary column. Add RecordID and ControlledRecordRef as Single line of text.

Microsoft Learn's text-column reference documents maxLength and allowMultipleLines; its column-definition reference documents required, enforceUniqueValues and defaults. Single-line text supports up to 255 characters, as explained in the linked Microsoft Support column-type guide; the smaller limits above are deliberate example settings.

Keep DEV-2026-0001 as text, not Number: its prefix, separators and leading zeros are meaningful. The 13-character maximum is not a format check; it still permits shorter or incorrectly structured values. Check the agreed pattern separately through a supported validation rule or a review assigned to a named person before relying on the ID. These settings use manually assigned IDs.

Uniqueness checks for RecordID concern this column in this list, not identifiers across every system. A required ControlledRecordRef only requires a value; reconcile it with the authoritative record to establish that it is the right reference. If users also need a clickable destination, consider a separate Hyperlink column alongside the controlled-record identifier.

Choice: status and classification

Use Choice rather than free text where the process requires a controlled vocabulary.

Microsoft Learn's choice-column reference documents the values (choices), manual entry (allowTextEntry) and presentation (displayAs). In the modern interface, the manual-entry setting may be labelled Can add values manually. Turn it off for both columns and use single selection so each record has one status and one classification.

An Open default reflects the starting state in this example. Classification has no default so the person entering the record must select a category. Define closure authority and approval steps separately from the available status labels.

Date and time: opened, due and closure dates

Choose Date and time as the column type and Date only as the format for this calendar-day example.

Microsoft Learn's date/time reference distinguishes dateOnly from dateTime, and standard date display from friendly relative display. Prefer a standard date display where available so users see a date rather than a relative label. Include the site's regional settings and any integration's date conversion in the test plan, including exports and API entry paths where used.

Leave defaults blank deliberately. Today's entry date may not be the event's opened date, and a default closure date could make an incomplete record appear closed. Keep ClosureDate optional at column level: making it always required would prevent the intended open-record state. The conditional requirement belongs in the list rule below. If your process needs event times, update all three definitions and their tests together.

Person or Group: accountable owner

Create Owner using Person or Group (shown as Person in some modern menus).

Microsoft Learn's person/group reference documents allowMultipleSelection, chooseFromType and displayAs. The proposed settings give each item one named accountable person rather than a free-text name or group assignment. Selecting an owner does not grant that person access or send a notification by itself. Define reassignment for leave, role changes and departed users; test access and any reminders separately.

3. Prepare the cross-field date and closure rule

Required fields and choice settings address individual values. To check relationships between fields, use a list-level formula in List settings > Validation settings. A calculated column displays a result rather than serving as this save-time check. Microsoft Learn documents a list validation element; Microsoft's formula examples explain the logical and blank-check functions used here.

For the exact column names and single-select Status above, this is a candidate formula to test:

=AND([DueDate]>=[OpenedDate],OR([Status]<>"Closed",NOT(ISBLANK([ClosureDate]))),OR(ISBLANK([ClosureDate]),[ClosureDate]>=[OpenedDate]))

Set a clear User message, for example:

Due date must be on or after opened date. Closed items need a closure date. Any closure date must be on or after opened date.

The three parts are intended to check due-date order, the conditional closure requirement and closure-date order. The intended logic permits an open item with a blank closure date and same-day dates. It leaves future-date checks, closure dates on open items and approval of status transitions outside this rule. Decide whether your process needs additional controls for those cases.

Keep requiredness enabled for OpenedDate, DueDate and Status; the formula is not a substitute for those settings. Check the formula editor accepts the expression in your environment, including column names and locale-specific separators. If a list already has a validation rule, combine the requirements and retain the existing checks. Confirm the rule's behaviour by running its positive, negative and boundary cases in the target list.

4. Write the test cases before running them

Use this baseline for the planned tests, with a matching synthetic controlled record:

Dates above use year-month-day notation for clarity; use the date picker and confirm the stored values. Save, reopen and compare every value with the baseline. Then change one thing at a time, restoring the baseline between tests. Use another unique ID whenever creating another valid item.

Before execution, list the ways a record can be created or changed in your environment. Include only routes that are enabled or permitted, such as the standard form, grid editing, an import, an approved flow, or an API integration. Record who can use each route and what controls or procedures are expected to apply. Include checks for fields hidden in a form but accessible through other permitted entry paths.

Record the configuration and user context for each test. Agree whether each control should prevent an invalid entry or detect it for correction before use; these require different expected outcomes.

Repeat applicable tests through each permitted entry path, including any relevant boundary cases such as an existing item being edited, an import being corrected, or a flow updating a record. All actual results deliberately remain Not tested in this pre-test plan. During execution, record the observed outcome, including any difference from the expected result.

If one path accepts a value another path rejects, record the difference as a control gap. Decide whether to restrict that route, add a suitable check, or manage the residual risk with an owned procedure. A successful test in one form covers that entry path, not every enabled route.

5. Define the evidence to capture

For the follow-up results review, capture the configured column settings and accepted formula, the test date, regional/time-zone settings, user permissions and entry path. Give each executed case a test ID and retain its input, expected outcome, observed outcome and a screenshot or other evidence reference. Keep screenshots limited to the test list and synthetic data.

If a setting is unavailable or a formula is rejected, record that as a result too. Document any correction and its retest separately so the review distinguishes the original design from the observed behaviour. The follow-up should explain both successful controls and remaining gaps.

For each critical field or rule, retain a short trace from requirement to evidence:

1. Requirement: what the field must represent and why it matters.
2. Failure: a foreseeable incorrect, missing or misleading value.
3. Control: the configured setting or procedure intended to prevent or detect it.
4. Verification: the test, entry path, expected result and actual result.
5. Owner: who approves the rule, reviews exceptions and maintains it after change.

Keep the dictionary, relevant list settings, test records and unresolved limitations together under the organisation's document-control practices. Reassess the controls when the register's purpose, field definitions, permissions, integrations or entry routes change. A choice list can constrain labels without authorising a status transition; a required field can require an answer without proving that answer is correct.

Where the register informs regulated quality decisions, assess its intended use and risks within the applicable quality system. Place these field checks within the wider validation and change-control work. For broader assurance context, see validating a SharePoint quality register and the quality-register overview.

Sources and scope

Microsoft documentation checked on 10 November 2026:

The settings, vocabulary, character limits and combined formula are proposed for this example, rather than prescribed by Microsoft. Available settings and API responses need to be checked in the target environment. For example, the column-definition reference notes that site/list column responses omit its validation property. Inspect the validation settings separately when recording the configuration.

No SharePoint tenant configuration or formula execution was performed for this article. The guide does not determine regulatory applicability or claim that these settings establish GMP compliance. Any interpretation of Good Manufacturing Practice (GMP) requirements needs a separate review of the applicable sources by a qualified reviewer.

Next step

Agree this configuration and its expected outcomes before running the tests. The follow-up article will use the SharePoint results to review which controls behaved as expected, where the design needed adjustment and what still requires a procedural check.

If you are assessing a move from a spreadsheet, use the Excel register migration and validation sign-off pack to frame the wider decision and handoff. Keep this field dictionary and test plan aligned with the register's intended use.