Workbench (Diver Platform 7.x) introduces the concept of discrete projects. Projects in Workbench are a collection of related files within a single directory tree that are associated with a Diver Solution or Diver Platform implementation.
The following are the main Workbench project features:
- Abstraction—what is the project for?
- Simplified file organization for required files
- Easily transportable—all pieces encapsulated
- Self-contained access control files
- Home Project feature to automate creation of user home directories
- Local user projects (for working offline) and support for retro projects (for 6.x projects not yet converted to 7.x)
Project Files
When you define a new project, a recommended structure is presented to organize the parts, but there is flexibility. You can choose to start with an empty structure or use the default structure and delete or rename folders to suit the needs of your project and reduce visual clutter.
A project directory typically has folders for:
- Raw data or source files
- Temporary data in the process of being manipulated
- Finalized data files
- Document libraries
- Image libraries
- Scripts, often organized by type such as build, divetab, or prd
The following is a typical 
project directory structure.
See Default Folder Structure for more information about the expected usage of the default directories.
See File Extensions for descriptions of new file types, their extensions, and the equivalents from earlier versions of the Diver Solution software tools.
Security
Access control is part of the project. Projects have self-contained access control rules that are organized by users, groups, or user properties. Access control options allow you to specify rules for accessing files and directories, rules for viewing data records in cBases, Models, DiveTab areas (buttons) and pages, as well as whole-project access.
Project Paths
Files within a project are referred to by their project path. The project root is a forward slash ("/"), and then all other files are stored under that. So if you have a folder called cbases within your project, and a sales.cbase file within it, the path to the file is:
/cbases/sales.cbase
Project paths make projects completely portable. A project can be stored in one place on one machine and in a completely different place on another. All references to project files within scripts are easily resolved regardless of the project placement on the server. Because of this, and in order to keep scripts, markers, and dives as clear as possible, the use of relative paths to reach parent or sibling directories (../data/foo.txt) is discouraged.
Aliases
You can create aliases to bring in data from outside the project. The aliases can be to folders in another project on the DiveLine or to a system drive. Alias functions are like a UNIX link.
Mailing Lists
Workbench maintains mailing lists on the project level to keep projects portable. You can create mailing lists that are used to send notifications for the success or failure of whole Production scripts or specific nodes as they are processed.