specs/models/M_APP_VER_STEP_SIGN

Signature Step

A Signature Step (Signature Form) is a variant of a Form Step that allows users to add an e-signature within an app running in the Tulip Player.

An e-signature can be:

Badge ID
LDAP Username/Password: If an organization uses LDAP to authenticate users in Tulip, then a user must input their username and password from their LDAP directory.
SAML Username/Password: If an organization uses SAML to authenticate users in Tulip, then a user must input their username and password from their SAML directory in a popup window.

An operator cannot proceed to the next step of an app until a qualified user has filled out the e-signature. The signatures cannot be autofilled- they must be signed via the permitted credentials each time they are presented.

An app builder can add one or multiple Signature Steps to an app.

Each E-signature from a Signature Step is recorded in a separate column in the list of Completions.

Fields

Name	Description
Submission Rules	The types of users that can sign the Approval Step. Options: Any User: Any operator can add a signature. Any operator besides app executor: Any operator can sign off EXCEPT the one that is currently logged in. Operator executing app: Only allow the currently logged-in operator to add a signature. Specify a list of allowed users: Choose from a list of all users and operators in a Tulip account. Multiple users allowed.
Approved Submitters (optional)	A list of Tulip users that are approved to sign the app in the Player
Signature Timestamp	The timestamp is applied based on when the Tulip user signed the Signature Step before the app was completed
Signer	The full name, user ID and profile image of the user that signed the Signature Step before the app was completed
Other	A required “Text” input widget can be used by the app developer to enforce signer to manually write reason for signature A “Dropdown” input widget with a list of options can be used to enforce signer to choose reason for signature

Tests

ID	Name
QA-T106	Signature Step : 01 - A signature form can be created
QA-T107	Signature Step : 02 - Signature widgets cannot be deleted from a signature form step and additional ones cannot be created
QA-T108	Signature Step : 03 - Signature form should allow any user to submit it when configured so
QA-T109	Signature Step : 04 - Signature form should allow only the current user to submit it when configured so
QA-T110	Signature Step : 05 - Signature forms should only be submittable a single time per process run
QA-T791	Widgets - 12: Widget Shift+Drag and Option+Drag Modifications

Requirements

ID	Requirement
PLAT-8869 (856)	Continuous signing sessions require two signature components for first signing but only one (secret) component for subsequent signings.
PLAT-8891 (816)	The manifestation of an electronic signature should contain the user's full name, date & time, meaning of signature human readable format; the record itself should contain these elements.
PLAT-8893 (815)	Provide an unalterable and enduring link between records and their associated electronic signatures; they cannot be removed, changed, copied, transferred or deleted.
PLAT-8902 (817)	Ability to require multiple electronic signatures for a record. Ie co-signer, verifier, etc.
PLAT-8904 (820)	Electronic signatures have to be secured and not allowed to be falsified. They can only be used by their genuine owners.
PLAT-8905 (819)	All electronic signatures have authenticate the signatoree by two distinct elements (e.g. username and password; at least one being a private element), or a secure unambiguous biometrics system that cannot be used by anyone other than their genuine owner.
PLAT-8906 (818)	If more than one signature is required the electronic signature shall capture the role of each signatoree. Eg. trainer, verifier, co-signer, etc.