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
19	Provide the ability to configure an e-signature requirement for any master data definition or model's status transition in the approval workflow
83	Ability to configure signature to complete a process step.
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.
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
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
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
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
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 e.g. supervisor signature, scrap, etc.
358	Provide configurable way to review exceptions
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.
815	Provide an unalterable and enduring link between records and their associated electronic signatures; they cannot be removed, changed, copied, transferred or deleted.
816	When capturing/acquiring an electronic signature the user must be able to see in human readable format the user's full name, date & time, meaning of signature; the record itself should contain these elements.
818	If more than one signature is required the electronic signature shall capture the role of each signatoree. Eg. trainer, verifier, co-signer, etc.
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.
820	Electronic signatures have to be secured and not allowed to be falsified. They can only be used by their genuine owners.
856	When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.