A "Version" defines the status of a SDI that belongs to a Versioned SDC. Versioned SDCs contain a "VersionId" primary key, and a "VersionStatus" column to indicate the status of the Versioned SDI:

The Version option in the SDC Maintenance page enables versioning for an SDC. Although this option is preset for Versioned Core and System SDCs, you can enable this option to version your own User SDCs as well.

Versioned SDCs contain a "New Version" button on the corresponding SDI List page. Using Parameter Lists as an example, the "New Version" button on the Parameter List List page creates a new Version of the selected Parameter List:

Clicking "New Version" creates a "Provisional" Version of the selected SDI (with the Version number incremented by 1) and opens the SDI Maintenance page for the new Version:

SDI List pages for Versioned SDCs should provide an "Expire Version" button to expire selected items. A confirmation message is issued before expiry. This transitions "Status" to "Expired". If required, you can create a "New Version" of the Expired Version.

This is the simplest Approval process for Versioned SDIs. The SDC Maintenance page for the relevant SDC has no Approval Types defined ("Version Approval Type" is blank), and the "Use Effective Date" option is disabled.

Edit the SDI, then click "Approve Version". Answer the confirmation dialog (asking if you really want to Approve the SDI).

Version Status transitions to "Current" for Version 1 of this SDI. The "Approval Date" is set.

This process lets you use Approval Types. The SDC Maintenance page for the relevant SDC is configured with an Approval Type ("Version Approval Type"). Once again, the "Use Effective Date" option is disabled.

Edit the SDI. Note that a "Send For Approval" button is added. Click "Send For Approval".

The SDI List page loads. From the List page, edit the SDI again. Click "Approve Version". Answer the confirmation dialog (asking if you really want to Approve the SDI).

The Approval Steps are shown. Choose the "Disposition". "Save" and ESig, the "Close & Refresh".

Version Status transitions to "Current" for Version 1 of this SDI. The "Approval Date" is set to the current date.

Here, the "Reset Approvals" button offers a rollback capability by resetting the Approval Status back to "Not Ready" if the status of SDI is still "Provisional" and some or all of the Approval Steps have been performed. "Reset Approvals" can also be used if the SDI has been sent for Approval but the Approval process has not yet started.

"Effective Date" is a feature that lets you specify an "Effective Date" on a Versioned SDI, such that an Approved Versioned SDI becomes active on the Effective Date. Although any Versioned SDC can be configured to provide this functionality, only these SDCs are configured OOB:

The SDC Maintenance page for the relevant SDC is configured with an Approval Type ("Version Approval Type"). This time, "Use Effective Date" is enabled.

Note that the "Effective Date" field has been added. The "Effective Date" can be set to the today's date or a date in the future. If left blank, it will be set to the current date during the Approval process.

Click "Send For Approval". This submits the Versioned SDI for Approval by calling the SubmitSDIForApproval Action with approvalfunction = 'Versioned'.

After submitting, you are returned to the SDI List page. Note the icon, indicating that the SDI is Pending Approval..

The Approval Steps are shown. Choose the "Disposition". "Save" and ESig, the "Close & Refresh".

Clicking "Approve Version" issues a confirmation dialog asking if you really want to Approve the SDI. Assuming "Effective Date" is a date in the future, "Approve Version" keeps the SDI in "Provisional" Status, and sets the "Approval Date" to the current date. The SDI will move to "Current" Status on the "Effective Date".

The "Reset Approvals" button offers a rollback capability by resetting the Approval Status back to "Not Ready" if the status of SDI is still "Provisional" and some or all of the Approval Steps have been performed.

SDI Approval With Effective Date and No Approval Types

The SDC Maintenance page for the relevant SDC has no Approval Types defined ("Version Approval Type" is blank), and the "Use Effective Date" option is enabled.

The "Reset Approvals" button offers a rollback capability by resetting the Approval Status back to "Not Ready" if the status of SDI is still "Provisional" and the "Approval Date" is not null.

Notes Concerning SDI Approval

Top

Here are some notes concerning various behaviors of the SDI Approval processes:

SDI Approval (In General)

•	If you click "Approve Version" for an SDI with "Current" Status, a message is issued indicating that "You cannot approve a Current SDI".
•	Note that if a "Version Approval Type" is not set for the SDC (you leave it blank), you will get only an "Approve Version " button for immediate Approval. The "Send For Approval" button is not available in this case. In addition to providing simplified immediate Approval, this ensures backward-compatibility with older LabVantage versions.

SDI Approval with Effective Date

•	After clicking "Approve Version", a warning is issued if the "Effective Date" is earlier than the "Effective Date" of other versions. "Yes" confirms to proceed with the Approval process, while "No" aborts the process.
•	The "Approve Version" process is done through the "UpdateSDIsToCurrent" Task. This is a Recurring Task that checks all SDIs belonging to Version-Controlled SDCs with "Use Effective Dating" enabled, then checks for any SDI that is "Provisional", has an "Approval Date", and an "Effective Date" that is in the past. The Task then calls the SetSdiversionStatus Action to make the SDI "Current". The Task honors both date and time.
•	"Effective Date" is validated. A warning is issued if the "Effective Date" is in the past. This warning ("Effective Date is before Today's Date") is issued if the "Effective Date" (ignoring time) is yesterday or earlier. Additional date validation options can be configured using the Columns → Validation → Date property of the maint Element for the relevant SDI Maintenance page:

Approval Using the sdidetailmaint Element

Top

Overview

A special mechanism for SDI Approvals uses the sdidetailmaint Element. An example of this can be seen in the OOB configuration for Incident SDIs. This mechanism provides these special features:

•

Copies approvals when Templates are used in the AddSDI Action.

•

Uses the preApprove and postApprove SDC Rules.

•

Uses the SDIApproval Detail Type in the sdidetailmaint Element.

•

Is supported by these Actions:

•	AddSDIApproval	•	EditSDIApprovalStep
•	AddSDIApprovalStep	•	ResetSDIApproval
•	ApproveSDIStep	•	SubmitSDIForApproval
•	DeleteSDIApproval

•

Provides the capability to add Approval Types and Approval Steps, as well as assign Users to each Step.

Assigning Users to Approval Types

Recall that when specifying Approval Steps for an Approval Type, the Approval Steps cannot be assigned to individual Users. When using the SDI Approval mechanism, Users are assigned when the Approval Steps are associated with an SDI. The example below shows how this is done with an Incident SDI, which supports SDI Approval OOB. Note that it has two Approval Steps. "Assigned To" lets you specify the User for each.

Additional functionality unique to the Approval form:

Button	Description
Add Type	Adds Approval Types.
Copy Step	Duplicates the selected row. This lets you associate the same Approval Type/Approval Step combination with more than one User (by choosing a different "Assigned To" for each).

Example of Approval Cycle

This example uses the OOB configuration for Incident SDIs.

After adding Approval Types and saving as shown above, the SDI is not yet ready to be Approved. This is indicated by a "Status" of "Not Ready".

Clicking "Send for Approval" issues an ESig prompt. After ESig authorization, the SDI is ready for Approval.

The SDI has been submitted for Approval, as indicated by a "Status" of "Pending".

Click "Approve/Reject".

In the resulting Approval page, select the "Disposition" that indicates your judgment, then enter a "Comment". Fields are editable only if the current User is defined by the Approval Type as a valid Approver.

After Saving, the page is read-only.

In this example, the Incident has been Accepted. The SDI has therefore been Approved.

The Maintenance List Page Type contains a Versions property collection that lets you filter Versioned SDIs in the List page by Version Status.

Products, Test Methods (Workitems), and QCMethods are Versioned. When you add a Product, Test (SDIWorkitem), or QCMethod to an SDI, that SDI always references the added item by its actual Version number. For example, if you add Version 1 of a Product to a Sample, that Sample thereafter references Version 1 of that Product.

SDI	Version	Version Status
Spec-001	1	Provisional
Spec-001	2	Current

SDI	Version	Version Status
Spec-001	1	Current
Spec-001	2	Active

Concepts of SDI Versioning and Approval

Content

SDI Versioning

Version Status

Creating a New Version

Expiring a Version

SDI Approval Without Approval Types

SDI Approval With Approval Types

SDI Approval With Effective Date

Overview

SDI Approval With Effective Date and Approval Types

SDI Approval With Effective Date and No Approval Types

Notes Concerning SDI Approval

Approval Using the sdidetailmaint Element

Overview

Assigning Users to Approval Types

Example of Approval Cycle

Filtering Version Status

Product, Test Method, and QCMethod Versioning

Version Status	Description	SDI Editable?
Provisional	When you create a new version of an SDI, its status is set to "Provisional". This indicates that the SDI is in the process of being configured for its intended purpose.	Yes
Current	Approving a "Provisional" SDI changes its status to "Current". There can be only one "Current" version of an SDI.	No
Active	When you Approve a "Provisional" SDI, the status of the prior ("Current") version is set to "Active".	No
Expired	"Provisional", "Current", and "Active" versions can be "Expired" when deemed not usable.	No

•	LV_ReagentType	•	ProtocolSDC
•	ParamList	•	SpecSDC
•	Product	•	Workitem

•	When you create a Sample or Batch, you can choose a specific Product Version. The Sample or Batch thereafter references the Product using that specific Version.
•	When adding Products to Sample Templates, you can choose to add the "Current" Product (see Versioning in Products).
•	The AddSDI Action accepts a Product Id without a Product Version. In this case, AddSDI determines the "Current" Product Version and references that specific Version. This is provided primarily for backward-compatibility.

•	When you add a Test (SDIWorkitem) to a Sample, you can choose a specific TestMethod (Workitem) Version. The Test thereafter references the Test Method using that specific Version. Note that WorkitemVersion is not part of the SDIWorkitem key.
•	The AddSDIWorkitem Action and ApplySDIWorkitem Action accept a Workitem Id without a Workitem Version. In this case, these Actions determine the "Current" Workitem Version and reference that specific Version. This is provided primarily for backward-compatibility.
•	The CreateSDI Scheduled Task, Stability Studies, and Stability Protocols let you reference the Workitem using a "Current" or specific Version.

•	When you create a QCBatch, you can choose a specific QCMethod Version. The QCBatch thereafter references the QCMethod using that specific Version.
•	The ApplyQCMethod Action and CreateQCBatch Action accept a Version number.