Requiring a specific E-form

A required document can be a specific E-form rather than any uploaded file. Set this with the @RequiredDocument data value on the Record, supplying the E-form's ID as the fifth part of the value or its name as the sixth. Only a document created from that E-form satisfies the requirement, so an uploaded file with a matching name and category will not clear it. Categories marked Required on the Record Type cannot name an E-form — the requirement has to come from an @RequiredDocument value.


Why saved does not mean complete

E-forms save every time someone works on them, so the presence of the form on the Record tells you nothing about whether the person finished it. A required E-form is therefore satisfied only when something says the form is complete. There are two ways to arrange that, and each requirement uses one or the other.


Option 1 — the form marks itself complete

Add a field named @RequiredDocumentComplete to the E-form. Its value is stored with the document when the form is saved, and the requirement counts as met when that value is a "yes" value — YES, Y, TRUE, T, 1, ON or CHECKED.


The simplest version is a checkbox the user ticks before saving. Use a standard checkbox rather than one with Multiple Interaction turned on: a Multiple Interaction checkbox writes nothing when it is unchecked, so a form marked complete once could never go back to incomplete.


To separate an ordinary Save from a deliberate Submit, make the field hidden and add a Submit button whose actions set it to YES and then save the form. Plain Save then leaves the form incomplete and only Submit marks it done, which is usually what people mean when they ask for a Submit button.


Nothing else can set this value — not a workflow action, not an add-in, not an administrator. The flag means "this form says it is finished", so the form is the only thing that writes it. If you need completion driven from outside the form, use the second option.


Option 2 — a Record field says the form is complete

Some processes already track completion on the Record — an approval status, or a checkbox someone ticks after reviewing. Name that field as the seventh part of the @RequiredDocument value and it becomes the deciding factor. The eighth part is the value that counts as complete: leave it empty and any "yes" value will do, or supply a value that must match exactly, ignoring capitalisation and surrounding spaces. A field that is missing or empty is never complete.


Because the field lives on the Record, anything that can write Record data can drive completion — a workflow action, an add-in, or a person editing the Record.


Choosing between them

A requirement uses one signal or the other, never both. When a Record field is named on the requirement, any @RequiredDocumentComplete value on the document is ignored, even if the form writes one. Use option 1 when the person filling in the form decides it is done, and option 2 when someone or something else decides after the fact.


The required documents still have to be present either way. The completion signal decides whether what is there counts as finished, not whether it exists.


Requirements that are not E-forms

A requirement that does not name an E-form is satisfied by the documents being present, exactly as before. Parameters 7 and 8 work on those requirements too if you want a document requirement to depend on something beyond the file existing, but nothing changes for requirements already in place.


What the rest of the system sees

Required document checks in workflow and the Missing Documents report treat a requirement as met or not met. A form that is saved but not complete counts as not met, the same as one that was never started. On the Record's Required panel the two cases are told apart visually — a started-but-unfinished requirement shows an amber marker rather than a red one — but that is a display distinction only.