What’s in a Name?

Hello and a belated Happy New Year!  Okay, so part of my New Year’s resolution was to post a blog a month.  It looks like I cut it a little too close.  Maybe I should officially change that to averaging a blog a month.  Ah, such is life as a ProjectWise consultant (hmmm, there is my next blog!)  Anyway, I digress.

I have had several requests over the last couple of months from users who are trying to establish a specific naming convention for documents being created in ProjectWise.  This is always a polarizing topic, spanning all verticals/disciplines.  ProjectWise does provide a mechanism to aide users with this process – albeit with a few kinks – called Document Coding (referred to as “code” for this post).

A code is simply a process that allows a user to uniquely name a document in ProjectWise, using a combination of Environment attribute fields separated by a character (or not).  While almost every organization can take advantage of a code, most will have different requirements.  Let’s take a look at a recent code I developed for one of my users:


PW Attribute Tab

In this example, the user had 6 requirements for their document name/filename: Year, Job, Unit, Discipline, Index and serial number (Seq).  The first step is to create a ProjectWise environment, which contains an attribute for each required code field.  In addition, I created (among other attributes not related to the code) a Drawing Number and Activity Description field.

Each attribute can be setup using a variety of ProjectWise options.  For example, the Year and Job (number) are automatically populated from their ProjectWise Project ‘Property’.  The Unit field is a basic ProjectWise attribute ‘Pick list’, while the Discipline and Index fields use the slightly more complicated ‘Look Up table’ methodology.  A Look Up table provides a user the means to develop pick lists using tables created in ProjectWise Explorer.  This allows a user the ability to add options to the pick list without having access to either ProjectWise Administrator (rarely) or the ProjectWise database (never).

The Discipline and Index fields form a ‘cascading’ pick list from the Look Up table.  In short, the options available in the Index are directly related to the Discipline selected.  The Seq or Serial Number field will automatically select the next available sequential number.  The Drawing Number field is a ProjectWise attribute identified by the code as a ‘Placeholder’.  This placeholder stores the complete code string, which can be delineated by a character.

The user requirement for this code presented an extra challenge.  The Index field is a 2-digit code that represents some sort of document type within their organization.  When the code pick lists are finished, there will be dozens of Index numbers (01, 02, 03, etc.) for each of their approximately 2 dozen Disciplines/Departments.  Users do not know, just by looking at the Index number, what type of document ‘Activity’ it is.  So the Index field had to include both its index number and description.  However, the description could not be part of the document name/filename when created.  This was achieved by writing a SELECT query in the Index attribute field that stripped the Activity Description from the Index field and place it in the Activity Description field.

As you might expect, the code process comes with pros and cons.  The main con is a Document Code can be broken.  Therefore, when using a Document Code, take into account the following:

A Document Code uniquely names a document based on a ProjectWise environment:  Many users believe it uniquely names a document within the datasource.  Not true.
A ProjectWise environment can only have 1 document code assigned:  If you have separate requirements for multiple disciplines/groups, this may constitute the need for a separate environment.
The Advanced Wizard (1): Is the only mechanism that works with a Document Code.  If a user creates a document using ‘No Wizard’, the Document Code is ignored.
The Advanced Wizard (2): Ensure that the Document Properties screen in the wizard is disabled.  If it is not, a user can overwrite the name/filename created by the code.
The Advanced Wizard (3): If you enable the ‘Create Document’ or Completion’ screens  in your Advanced Wizard (which appear after the Document Code screen), the user can hit the ‘Back’ button, which will automatically enable the Document Properties page, even if it is disabled!
No Wizard: Use of this option bypasses the Document Code, even if the parent folder has the environment set.  Note that this is working as designed.  It provides flexibility to create multiple document types within the same environment.  For example, you might create a Document Code for use with CAD drawings only.  However, the same environment may be used for other types of documents.
The Attributes > Document Code command: Look at the snapshot above.  All of the code fields appear to be read only.  Perfect!  However, that is not possible for the attributes that are pick lists.  They are simply greyed out because they are attributes of the code, which appear as read-only on the Document Attribute Tab.  If a user uses this command, they could modify the code attributes.
The Excel Import/Export Tool: Care must be taken when importing documents that are associated to a code.  The Import tool does not read or validate these attributes.
Code Field Separators: There are several default characters that you can select from.  But did you know that if a character is not listed (for example, the ‘_’),  you can simply enter it as your deliminator?
Document Code Restrictions: Restricts users to a range of numbers when creating a document code. Three types of restrictions can be created: Allow, Forbid, or Reserve.

If some of these options frustrate you (as it does me from time to time), consider that having a Document Code in place is usually better then having no process at all!  Many of these issues can be avoided with proper internal ProjectWise training and good security practices.


2 thoughts on “What’s in a Name?

  1. Hi Bill,
    Came across your blog as I searched for anything on document coding.
    My question, is anything available to a user or administrator in Projectwise (PW) that can show the un-used document codes that have been asigned? Like a map of unused codes.
    For instance someone uses the next available command and this leaves blocks of codes skipped. Then I need to find a block of codes in the skipped area large enough to code all my files in sequence? I am working along doc coding files and oh no someone has used one of the
    numbers I was intending to use. If I could somehow see what has been used I could avoid this file coded in my way.
    Thanks, Scott

    • Hi Scott…As far as I know, nothing is available within the ProjectWise interface. If that’s correct, you likely have a couple of options. One is ProjectWise customization through Bentley Professional Services. Another suggestion is if you have a DBA (or you are comfortable enough with either SQL or Oracle), you could try and write a database report using SSRS or an equal product. I believe that the code restrictions are stored in the dms_ecdr table and the name/filename would be stored in the dms_doc table.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s