The backbone to Altium Designer's design data management capabilities is the vault that stores your precious data. An Altium Vault can store a broad variety of data, including: components (and their models); managed content (such as templates and managed sheets); and the output fileset from you released board designs. Each component, template or released output fileset is stored in the vault as an Item.

As well as storing different types of data, the vault also stores the complete history of that data. It does that using the concept of revisions – each time the original design data requires a releasable design update, it is re-released into the vault as a new revision of that Item. Revisioning ensures that you have complete traceability of all of your data throughout its life, as well as access to any revision, essential when an existing product must continue to use an older revision of an Item. To ensure the correct revision is being used, each Item is always identified as an Item-Revision. As well as being revisioned, each Item-Revision also has a Lifecycle State. The Lifecycle State reflects the 'readiness' of the Item-Revision for use in a product, for example it could be In Design, For Prototype, or For Production.

To use an Item-Revision in a design you access it through Altium Designer's Vaults panel. To manage the Revision or Lifecycle state of that Item-Revision from within Altium Designer, you use the Item View.

Opening the Item View

The Item View provides a highly detailed view of the Revision and Lifecycle history of a specific Item, as well as showing all of the elements that make up that Item. The Item View is also where you manage and increment the Revision and the Lifecycle states. To open the Item View, locate the required Item in the Vaults panel, right click on it and select Full Item Details from the floating menu.

Understanding the Graphical Elements in the Item View

While the graphical elements in the Item View might initially seem confusing, it's functionality is straightforward. It is important to point out that the set of graphical elements used for a specific Item actually depends on the Revision Naming Scheme and Lifecycle Definitions chosen for that Item. That said, the overall behavior of the Item View is consistent regardless of the Scheme and Definition chosen, a more detailed Revision Naming Scheme or Lifecycle Definition simply adds more detail into the View.

Since the detail and arrangement of the graphical display presented in the Item View is directly related to the chosen Revision Naming Scheme and Lifecycle Definitions, the following discussion and images center around a 3-Level Revision Naming Scheme and a Structured Lifecycle with Approvals.

The Connection Between the Item View and the Revision Naming Scheme

Main article: Item Revision Naming Schemes

The Item shown in the image above uses a 3-level Revision Naming Scheme. Each Revision of that Item has a dark grey caption, for example Rev. 02.A.1. The cluster of cells below the Revision caption shows the different Lifecycle States that that revision has been through.

The image below shows the relationship between the chosen Revision Naming Scheme and how those revisions are presented in the Item View. Consider the Revision 02.A.1 in the image. Breaking down this 3-Level Naming Scheme, you can see Model 02 at the top of the Item View. Note that the Caption text Model was defined in the Revision Naming Scheme dialog, along with the ID Format as Numeric, with a Width of 2. Below the Model in the Item View is the text Prototype 02.A, and below that is the first revision of this Model-Prototype, Revision 1. The Prototype and Revision Caption string, ID Format and Width are also defined as part of the chosen Revision Naming Scheme. This gives the complete Revision Name of 02.A.1 for this particular revision.

The ability to define the number of levels and the detail of the naming scheme ensures you can select a scheme that best reflects the needs of your organization. In this example the Model is used to identify the model of the project that is ultimately sold, to use Apple® as an example, think of the iPhone® 3, followed by the iPhone® 4. A new Model would only be released when there were significant feature changes made to the product.

At the next level down, a new Prototype would indicate that design changes were needed, perhaps to resolve a technical issue in a released Model. A change at the lowest level, the Revision level, indicates that a minor design change was needed. Changes at the lowest Revision level would typically happen when that Model of the product is still in development, before it makes it into Prototype.

The Revision Naming Scheme can be a simple, single-level numeric value, up to a maximum of a 3-Level Naming Scheme, as discussed previously. Custom Schemes can be defined. To learn more about naming schemes read the article, Item Revision Naming Schemes.

The 2-Dimensional Nature of the Item View

The Item View presents all of the Revisions of a specific Prototype/Model in a vertical column. If a single level naming scheme is used then there are only Revisions (no Prototypes or Models), so all releases will appear in the first column. If a 2-level naming scheme is used, then all revisions of a specific major release will appear in a single column. Each new major release is presented in the horizontal direction, starting a new column in the Item View, as shown by the middle section of the image below. If a 3-level naming scheme is used then all revisions of a specific Prototype are in a single column. Each new Prototype then starts a new column, but still under the same highest level Model heading. Each new Model starts a completely separate column in the Item View, as shown in the right-hand section of the image below.

Changing the Revision or Lifecycle State

Both the Revision and Lifecycle State can be incremented in the Item View, using the right-click menu. The menu entries for Lifecycle-type changes are toward the middle of the menu, as shown in the image below. The options available (including the displayed menu text), are determined by the valid Transitions defined for the current Lifecycle state of the Item. The menu entries for Revision-type changes always appear at the bottom of the right-click menu.

While establishing a new Revision or Promoting the Lifecycle are completely separate tasks that are done for different reasons (a new revision when there is a design change, a new lifecycle state to reflect the enhanced usability of that Item), they are inter-related, so it is worth discussing them together.

Just how are they interrelated, you ask? When an Item is to move from one Lifecycle State to another State, this process is called a Transition. Allowed transitions are defined as part of each State definition, defining the target state that a given transition can move to. When you right-click on a cell in the Item View to perform a Lifecycle State change, it is the allowed Transitions that appear as available menu entries (the actual menu text is defined as part of the Transition in the Lifecycle Definitions dialog).

The Lifecycle States can also be clustered into Stages, if they are then the Stages can be linked to the revision levels of the revision naming scheme using the option at the bottom of the Lifecycle Definitions dialog. This creates the relationship between the Lifecycle State and the Revision level that was mentioned previously. What that means is when an Item's Lifecycle is incremented so that it moves from a Lifecycle State in one stage to a Lifecycle State in the next stage, then the available Revision modification type commands will change too. For example, when the Item was New From Design, then the Revision-type options include: establish a new Revision; a new Prototype; or a new Model. If the Lifecycle is then incremented to the point where it is now In Prototype, it will have moved to the second stage. Right-clicking on it now, the available Revision-type options now include: establish a new Prototype; or a new Model, that is, there is no option to start a new Revision. This behavior is what you would intuitively expect, if the design has progressed to Prototype, then if a design change was needed you would expect to have to release a new Prototype, or even a new Model, depending on the scope of that change. If that level of control is not required in your organization you can disable the Link Stages to the revision levels of revision naming scheme option at the bottom of the Lifecycle Definitions dialog for your chosen Lifecycle Definition.

The Item View Timeline

The Item View includes a Timeline. Use the Timeline to examine the exact time and date of any change made to the Revision level or Lifecycle State of that Item. The Timeline also lists the user who made each change. To simplify the task of interpreting the Timeline, when you click on an entry in the Timeline, that cell is highlighted in the main region of the Item View and all following Revision/Lifecycle changes are temporarily grayed out.

The Timeline also includes a Menu button, as shown in the image below. Use this to limit the amount of data shown in the Item View, to just Models, or Models and Prototypes. This could be useful if there is a large number of releases for a particular Item. Select Refresh on the menu, or click the Refresh button to restore the full view of that Item.

Accessing Release Data

One of the main advantages to using an Altium Vault is being able to access all of the release data from a central, single location. That data forms the "instructions" for actually manufacturing the item - such as ODB++ or Gerber files, design reports, Bill Of Materials, and a snapshot of the design documents that were used to create those instructions. Once you have released your outputs into a particular revision, those "instructions" can be accessed via the Item View, or via the right-click menu in the Vaults panel.

Released Documents

The Released Documents pane in the Item View shows the output containers that have been released into the vault for the selected item and revision. You can access the folder structures created for the manufacturing files (Gerbers, N.C. Drills etc.), PDF documents, and videos that have been created during the release process - as defined in your Output Job Files. You can download this released data using the right-click menu within the Released Documents pane.

Design Snapshot

The "snapshot in time" - taken from the Design Repository at the time of release - is also stored in the Altium Vault. Access to these design documents is provided via the right-click menu within the Design Snapshot pane of the Item View. Choosing to download the design snapshot will prompt you to choose a local folder in which to save the downloaded design documents.

Bill Of Materials

Another key component of the release process is the generation of a Release BOM. This is a separate BOM, generated at release time and stored in the vault as an XML document - not to be confused with user-defined BOM which is driven from the Output Job Files in the project. Download this BOM in XML (an .xml file), with an XML schema (an .XSL file), by right-clicking in the Item View BOM pane, and choosing Download BOM - at which point you will be prompted to specify a local folder in which to save the document and schema. This XML based BOM is particularly useful for importing the release's BOM into systems used by other parts of the organization outside the electronics design team.

Publishing Released Data

Main article: Publishing Destinations

From within the Item view, you have the ability to publish released documents for any Item Revision, to any hosted storage space defined within your Publishing Destinations preferences. Currently supported hosting destinations include Box.net, Amazon S3, and standard FTP servers. In terms of distribution and collaboration, this provides an unparalleled advantage in a world where the collective members of the overall 'product team' – the design team, the manufacturing team and all others involved in the process of getting a product from thought to reality – are often dispersed around the globe.

As mentioned, only the Released Documents can be published – the generated validation reports and outputs from Output Job files assigned to the project configuration that was released. To publish, simply select the Item Revision whose documents are to be published, right-click anywhere within the Released Documents pane, or on the revision itself in the graphical lifecycle view above, and choose the required destination from the Publish Released Documents To sub-menu. The sub-menu lists all available publishing destinations, by name, as defined on the Data Management – Publishing Destinations page of the Preferences dialog. Use the subsequent Publish to dialog to define the required destination sub-folder in which to store the data, and also to determine – through email – who to share the published data with.