6.3. About Terminology

Term

Definition

action

Actions are units of work that are fired in response to form events.

For example, sending an email containing a hyperlink to a document or displaying an alert message.

alert

A message box that is displayed to the end user during the data entry process.

authentication provider

See provider.

batch signing

A feature that allows you to sign multiple documents with a single signature.

bulk signing

A feature that allows you to sign multiple signature fields, in a single document, with a single signature.

boolean logic

A rule based on true or false, yes or no or the presence of one of two clearly opposed values.

calculated field

A field that is calculated by, or from a value(s) of another field.

click wrap signature

A type of signature whereby a user enters in their name and it is inserted into the generated document.

client ID

A container within LincDoc that stores all field definitions, source documents, generated documents and data. These cannot be created at the user level, but instead are directly tied to your license key - as created when you acquired LincDoc. In most cases, you will only have access to a single client ID, although multiple client IDs can be purchased, if needed.

codelist (code list)

Codelists are objects within LincDoc that drive drop down choice lists.

For example, a form question that has a yes/no answer.

There are multiple types of codelists available, including simple, advanced, and JDBC.

condition

Conditions are Boolean expressions that are evaluated throughout the lifecycle of an eForm in response to form events. When the conditions are true, then certain actions are allowed to happen based on the configuration of the eForm.

condition to display

Logic used to conditionally display or hide a field or section. Sometimes abbreviated as "c2d".

conditional text/paragraph

Refers to a snippet of text inside a Microsoft Word (or OpenOffice) source document that is conditionally shown in a generated document. The condition of the text is evaluated at document generation time, if the condition is true then the text is included else it is not included.

CSV

Short for Comma Separated Values, which is a type of text output where each field's value is separated by a comma. Values that may contain commas may be surrounded by double quote characters.

For example: "Jane","Smith","123 Main Street","Southtown","IL","65099"

DANG

Short for Data And Number Generator, which is a key component of the LincDoc administrator interfaced used to create conditions, actions, and calculations.

data entry

The term used to describe the process of an end user filling out the form fields of a particular eForm or Document Package.

DDL

Acronym for drop-down list.

document

A file created using an eForm of Document Package. Basically the "filled-in" version of an eForm or Document Package. Also known as a generated document.

document inclusion logic

Boolean logic rule that selects a document based on the existence of a specific field or fields.

Document Package

Extends what an eForm can do by allowing one or many related Word or PDF source documents to be assembled based on predefined business logic.

document repository

A searchable storage area where documents and data are saved. LincDoc has its own internal document repository, and third party repositories such as Laserfiche are also supported.

document viewer

The window in which the generated document is displayed.

DRAT

Short for Document Refinement Annotation Transformer, which is an extension of the LincDoc markup language for more sophisticated field resolution scenarios.

drop-down list (DDL)

An eForm control that when clicked on presents a list of choices from which the user must choose one.

eForm

An electronic web form composed of a single Microsoft Word or PDF document. The document contains zero or more field placeholders. It is also comprised of field details, sections, conditions, actions, events, and lookups.

end user

Any person who uses LincDoc to complete a preconfigured eForm or Document Package.

event

Help describe significant points in time during the lifecycle of an eForm or Document Package.

Examples of events include "on load" which fires when an eForm is first executed, or "on generate" which fires when the end user has completed the data entry process and is ready to generate their document.

field

A placeholder inside a source document for the purpose of filling with data either manually or from a database.

fields document

A source document used for the sole intention of field placeholders only, it is never meant to be part of a generated document. This technique is often used with more complex document packages which have many source documents: the fields document consolidates LincDoc fields to a single entity.

flattening

The processes of removing the ability to change field values in a PDF form.

function

A system calculation that returns a single value given zero or more inputs.

generated document

See document.

global field

Field definitions that can be applied to any field of the same name or pattern when creating a new eForm.

inclusion logic

The use of Boolean logic to determine if a paragraph or document should be included when generating a new document.

input constraint

A simple input mask or regular expression that can be applied to a field to enforce what data is allowed for a field.

JDBC

Short for Java Database Connectivity.

LDAP signature

A type of signature in LincDoc whereby the user "signs" the document by being prompted to re-enter their LDAP password at the time of signing. Often used in combination with the Active Directory integration module.

LDAR

Short for LincDoc Archive. An eForm definition can be exported as an .ldar file, and imported to another LincDoc VM.

LincDoc administrator

The person responsible for creating eForms and corresponding field elements, conditions, lookups, actions, etc. within the LincDoc system for the end user community.

LincDoc markup language

The term used for "<<...>>" and "<<<...>>>" expressions inside Microsoft Word documents that respectively identify fields and conditional paragraphs.

lookup

A query that searches for data in an external system.

LWSA

Short for LincWare System Administration Portal. Portal for all server level configuration options.

multi-phase signatures

The term is used to describe a document that contains multiple signature fields, and those signatures are not all signed in the same browser session: the signatures happen in different phases.

multitenancy

A type of software architecture where a single instance (installation) of the software runs on a server, but is designed to virtually partition (divide) its data and configuration. In this arrangement, each client organization (known as client IDs in LincDoc) uses a customized, virtual application.

In the LincDoc environment, multitenancy is used to separate sets of forms and data.

multi-value field

A repeatable field that takes on multiple values. These are sometimes called "multi-row fields" or "pound fields" (because in the LincDoc markup language they are always terminated by a pound sign (#)). These field types are only available in Word source documents.

Example:

• An eForm that captures a list of part numbers. 
• A field that captures multiple quantities would be marked as quantity# and would represent quantity1, quantity2, quantity3, etc.

node

A specific item within a repository, accessed via the Browse dialog box. Nodes can be documents, files, or folders.

OpenForm

The term used to describe when an eForm is launched in a separate browser window (or iframe), and none of the normal LincDoc desktop controls are present (for example, no top toolbar with buttons for search, run, help, logout, etc.).

This method is the preferred way to run eForms for end users because it is very directed in the sense that all they can do is complete the form in front of them.

paragraph inclusion logic

A condition that shows or hides a paragraph in a generated document. Only applies to Word source documents.

parse/reparse

The process of resolving/finding fields in a document. A reparse operation typically takes place whenever a source document is altered.

PDF

Acronym for "portable document format".

pound field

Another name for a multivalue field.

provider

Also known as authentication provider. Acts as a container for a specific set of users and groups. They can be created to control application access. They are created at the client ID level, making them available to other users with access to your current client ID.

required condition

Refers to a condition attached to a particular field that determines if the field must be non-blank before proceeding. Just before document generation time the condition is evaluated. If it is true and the corresponding field is blank then processing stops – the user is shown a warning message that they must fill in the field before proceeding.

section

The term for a container/area within an eForm that contains one or more related fields.

signature

Both a person's name, used to formalize a document, as well as a general term for the information that applies to all form fields to which a signature itself is applied. For more information, see About Signatures and Stamps.

signature receipt

A signature feature that displays the actual signature used on a form, information about the signature (such as the name of the user who signed and the date/time), and provides buttons for downloading the corresponding signed form or just the receipt information to a file.

signature stamp

An image that can be used in place of a script font representation of a signature, and is a digital representation of your actual signature. For more information, see Using Signature Stamps.

source document

A Microsoft Word or PDF document containing zero or more fields. In the case of Word, the LincDoc markup language is used to denote fields. For PDF, FDF fields are used. Adobe Lifecycle forms are also supported. 

source document library (templates)

The library of documents available to users in LincDoc.

SQL repository

A back end storage system that is based on a relational database. Currently, this database must be either PostgreSQL or Microsoft SQL Server.

Note: This feature is available with LincDoc version 3.3 and later releases.

subject matter expert

When designing a new eForm, this is the person who has the knowledge and expertise to provide guidance on the finer details of the form. This person also has a thorough understanding of the business processes and high level workflow logic that often accompany an eForm.

stamp

An electronic record, used with signatures, that captures details essential to demonstrate the authenticity of the signature. For more information, see About Signatures and Stamps.

superuser

Similar to a Windows Administrator account, this type of user is given access to a large majority of the LincDoc system and its settings. Typically, a non-cloud installation has only one superuser account called admin. Cloud installations never have a superuser account for security reasons. 

synchronization/sync/on sync

An event indicating that a mobile device (for example, an iPad) is pushing locally saved forms/data to a LincDoc server.

TIFF

Short for "tagged image file format".

token based name

Used to describe the process of substituting tokens for form field values, especially in the case of naming a generated document.

For example, the admin can create a token based name in which one of the tokens is the "lastName" field collected from an eForm, plus other tokens for the current date, followed by the file type ".pdf".

Topaz signature

A type of signature using one of the supported devices offered by Topaz.

TortoiseSVN

An optional third-party plugin for MS Windows Explorer that allows administrators to check-in and check-out documents and eForms.

UI

Short for "user interface" or the portion of the application with which users directly interact.

UUID

UUID (Universally Unique IDentifier) values can be thought of as random strings such as: 7402b0a6-d4da-489b-9955-8cc3f87735cb. UUID generators are very good at never producing the same string twice.

For every document generated in LincDoc (regardless of the repository type: SQL Repository, Laserfiche, or Docuware), a UUID is assigned that is 36 characters long. The DANG function DocID can be used to return this value.

The value is actually internally generated the moment you start a brand new form (and never changes for that form thereafter). This value is critical to doing any kind of workflow with a document, and is used to create URLs that allow direct access to manipulate a particular form (editing, viewing, signing, etc.). 

For more information on UUIDs, click here.

use case

This term refers to describing a situation that highlights a particular set of features and/or requirements of an eForm. For example, a form that requires several signatures from the same signee is a good "use case" for LincDoc's bulk signing feature.

user

Short for "end user".

user profile

Stores the user's name, email address, time zone, password, and password reset question.