Signature fields record a user and a timestamp of when they are signed. They also store a flag indicating whether they were signed via a simple checkbox or via a "secure digital signature." Searching of signature fields is limited to the timestamp portion. Searching for a null or non-null timestamp allows detecting signed and unsigned fields. Aside from the standard features shared by most field types, signature fields have a number of format options and they can be used for conditional locking and hiding. These two feature categories are discussed below.
One truly unique and vital feature of signatures is they cannot be filled out via formula. This is to ensure the integrity of the signature. If signature fields could be filled out by formula, there would be effectively no evidence that a user even looked at the data being signed. It would be purely a matter of the word of the formula author versus the word of the signer. This would entirely defeat the purpose of a signature which is to assure that the person signing was in fact using the site, did view the data, and did actively choose to sign the signature field.
Signature fields can, however, be unsigned via formula. This allows a signature field to be re-used when, for instance, the other fields on the form are changed and re-verification of the data is required. Normally users are not allowed to unsign their own signature as this would defeat the purpose of most signatures. However, an organization administrator or BlueStep super user may manually unsign signature fields in most cases.
A signature field has two main styles and a credential option.
| Format/Setting |
Description |
| Simple |
A simple signature, or checkbox signature, consists of a checkbox with a label to the right and optional main label. By checking the box the currently logged in user is "signing" the field and their user account is attached to the field and a timestamp recorded. Note that the account is attached, not the user's legal name, not their username, etc. The signature is attached to the currently logged in user's account. After signing, the checkbox label is replaced by the signing user's first and last name, optional credential and the timestamp. Unless the current user is an org. admin. the field also becomes read-only upon signing and the checkbox is absent. |
| Digital Signature |
This field is actually two fields, a text field and a password field. The text field is for a username, and it can be any active user in the system whether currently logged in or otherwise. The password field is for the user's signature passcode, NOT their regular password. Users must apply for a passcode by completing the application process. The process is started from the user's "My Account" area. It is completed by mailing to BlueStep a notarized statement (created during the application process) that the digital signatures signed with their passcode shall be legally binding. Upon receipt of the notarized document, BlueStep client care will activate the user's passcode.
Upon successfully signing the field, the appearance looks exactly like a simple signature field except there is a small lock icon indicating that this field was signed by the "secured" method. Clicking the lock displays a pop-up message explaining the security features of this type of signature and information from the user's passcode application process.
Benefits: Aside from being even more legally binding than a simple checkbox, user's with an on-file noterized document have a known identity verified by the notery public who certified the document. Also, this style of field can be filled out by a user who is not currently logged in. For instance multiple signature fields on a layout can each be signed by a different person by taking turns at the keyboard. Also, this type of field can be permissioned so that the person signing it does not have permission to sign under their own login. They must sign in the presence of another user who does have permission to edit the signature field.
|
| Display Credential |
This option is only visible if a staff credential form has been properly configured. A properly configured credential form must have 5 elements:
- It must be a multi-entry form.
- The form must be attached to the individual record type or to one or more categories attached to the individual record type. Usually this is a staff category or the user category.
- It must have a date or date/time field which records when the credential became effective. The date field must have a fixed id of 745.
- It must have a field which contains the displayable name of the credential. The credential field must have a fixed id of 744. This is usually a text field of some variety.
- Both of these fields must be filled out on every entry of the form. Usually this is done by making them both required.
If the "display credential" option is selected, then then system will go to the user account of the signer. It then looks for the credential form to see if it is attached to the account (if the user's account has the category that the credential form is attached to). Finally, it searches the list of the user's credentials for the entry with a date/time before or equal to the signature timestamp and after all other credentials which are before the signature timestamp. In other words, it looks for the most recent credential prior to signing. Note that this system allows credentials to be attached retroactively to existing signed signature fields and to fields which previously did not have this option selected.
|
Conditional locking is a general feature that is available on most field types. It allows almost any field to be conditionally made read-only (locked) or hidden based on the value of another field. However, only certain types of fields may be part of the condition which causes the locking/hiding. Signature fields are one of the field types that support this. The locking/hiding settings are configured on the field to be locked/hidden, not on the signature field, but they are documented here because each type of field which may be the condition of the lock is a bit different. Conditional locking and hiding is always done before the page displays. If the user changes the value of the signature field after the page is displayed no fields will instantly become locked or unlocked, visible or hidden. Conditional locking/hiding effects fields whether they are shown as part of the generic layout or as part of a custom layout.
Signature fields may conditionally lock/hide other fields by being either signed or unsigned.
Print
PDF