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

Requirements

ID	Requirement
PLAT-8743 (296)	Prompt for, verify and capture an e-signature as part of a step execution if an e-signature is required in the step's configuration
PLAT-8752 (298)	Require e-signature for exception of specific configured risk categories. Ie for high severity or high risk exception require the capture of an e-signature in the history record
PLAT-8754 (358)	Provide configurable way to review exceptions
PLAT-8817 (151)	Ability to configure allowed overrides for steps and procedural elements. An override can be allowed for out of spec conditions and can require additional approval using e-signature
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-8896 (809)	All records and electronic signatures have to include an accurate date and time stamp. Date & time stamps shall be configurable with the possibility to include the day, month, year, hour, minutes, seconds and time zone.
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.
PLAT-8921 (330)	Ability to automatically or manually log an exception when data is not within configured limits and tolerances. Disallow process completion until exceptions have been logged with configured e-signatures and any authorized overrides have been processed
PLAT-8931 (19)	Provide the ability to configure an e-signature requirement for any master data definition or model's status transition in the approval workflow
PLAT-8972 (83)	Ability to configure signature to complete a process step.
PLAT-8982 (87)	Content screens can be populated to the extent possible based on context of entered data. Ie. text fields, drop downs for users to selection, etc.