Allowable COBie Values #1: The Contact Sheet

by | May 27, 2025 | BIM, News

Welcome to the first in a series of short blog posts that will explain in plain language the allowable values you can enter for COBie field. It is intended to be a quick reference to “delivering COBie”. We want to answer the question of what data to you need to enter into Revit, ArchiCAD, OpenBuildings Designer (delete as appropriate) to achieve COBie.

This blog will be referring to the COBie standard: NBIMS-US_V3_4.2_COBie.pdf

SERIES FORMAT

Each blog post will go through a series of fields in the following COBie worksheets, providing the definition of the data that may be entered alongside an explanation where required:

  • Contact
  • Facility
  • Floor
  • Zone
  • Space
  • Type
  • Component

These blogs will be supported by our example COBie XLSX which will be updated alongside each blog post.

Before we jump into the worksheets themselves, a brief word on the colour coding used in COBie:

Yellow means this is the basic information that constitutes COBie, i.e. it is required.

If a client wants extra COBie information, the green if specified as required comes into play. These are optional extras that the Client should specify are required. If not they will only receive the default required information (confusing language I know!). So, if a client asks for any other additional information, it is technically no longer COBie, even though it may look like it. If a client asks for COBie, but does not specify the required green information, they should only receive the required yellow information.

This series of blogs will be focussing on required (yellow) and if specified as required (green), but the other colours are:

  • Orange which indicates a cross-reference to another COBie sheet (i.e. to yellow or green information)
  • Purple which is automatically generated by the authoring software so they do not require too much consideration, but they will be explained where appropriate.
  • Grey relates to secondary information, which we will not be covering.

COBie.CONTACT WORKSHEET

Contact (NBIMS V3 – 4.2.3.2.2.2)

“A worksheet in the COBie spreadsheet.  Each row in the Contact worksheet identifies a person or company referenced elsewhere in a COBie spreadsheet.  Contact.Email is the primary key for this worksheet.”

This is how the contact worksheet is used within COBie. It needs to identify the source of the relevant COBie information populating the rest of the worksheets. This could be a company or a person.

The term ‘primary key’ means that Contact.Email is the field that is used to identify each individual Contact in the worksheet.

ALLOWABLE COLUMN VALUES

  1. Email (NBIMS V3 – 4.2.3.2.2.2)

“A well-formed email address used to identify this specific Contact.”

This must be a unique email address. This does not necessarily have to be a personal email address, a generic office or project based one would suffice.

  1. CreatedBy (NBIMS V3 – 4.2.3.2.1.1)

“the contact email of the person or company creating or updating a row of COBie data”

CreatedOn (NBIMS V3 – 4.2.3.2.1.2)

“the date on which the information provided in a row of COBie data was created or updated by the person or company identified in the created by field.”

CreatedBy is a lookup to the Email column, so the CreatedBy and Email will be the same. CreatedOn is the date this row was created or updated.

  1. Category (NBIMS V3 – 4.2.3.2.2.3)

“the category of business in which the specific Contact is engaged.  If allowable values are not specified by contract, the default value for this information is the current OmniClass Table 34.”

Following ISO 19650-4 NA.2.1.2 Table 4 this would be the Uniclass Role (Ro) classification of the company. So an architect would be “Ro_50_10_03 : Architect”, an Information Manager would be “Ro_30_10_42 : Information manager” and so on.

  1. Company (NBIMS V3 – 4.2.3.2.2.4)

“the name of the company for the Contact.”

Phone (NBIMS V3 – 4.2.3.2.2.5)

“the telephone number for the Contact”

Both pretty self-explanatory.

  1. ExtSystem (NBIMS V3 – 4.2.3.2.1.3)

ExtObject (NBIMS V3 – 4.2.3.2.1.4)

ExtIdentifier (NBIMS V3 – 4.2.3.2.1.5)

All three of these columns relate to identifying the contact within the authoring software and will be populated automatically.

These columns are automatically generated by the authoring software, and on this worksheet all the ExtObjects should be IfcPersonAndOrganization.

  1. Department (NBIMS V3 – 4.2.3.2.2.6)

“the name of the department for the Contact.”

As the colour denotes, this field only needs to be completed if specified. This could be “n/a” if there is no applicable department to your organisation; it should be “n/a” if it is not specified as required by the contract, but it cannot be empty.

  1. OrganizationCode (NBIMS V3 – 4.2.3.2.2.7)

“the organizational code for the Contact.”

This should align with the code used in your information container naming for your organisation. This would normally be defined in the project Information Standard and confirmed in the BIM Execution Plan.

  1. GivenName (NBIMS V3 – 4.2.3.2.2.8)

“if the Contact is a person, the given name of the Contact.”

FamilyName (NBIMS V3 – 4.2.3.2.2.9)

“if the Contact is a person, the family name of the Contact.”

If the contact is a person then these are straightforward fields to complete. If it is a company, then “n/a” is acceptable to complete the field as it cannot be blank.

  1. Street (NBIMS V3 – 4.2.3.2.2.10)

“the street address for the Contact.”

PostalBox (NBIMS V3 – 4.2.3.2.2.11)

“the postal box address for the Contact.”

Town (NBIMS V3 – 4.2.3.2.2.12)

“the city or town address for the Contact.”

StateRegion (NBIMS V3 – 4.2.3.2.2.13)

“the state or regional address for the Contact.”

PostalCode (NBIMS V3 –  4.2.3.2.2.14)

“the zip, or postal code, address for the Contact.”

Country (NBIMS V3 – 4.2.3.2.2.15)

“the country for the Contact.”

All these make up the postal address of the contact.

EXAMPLE

Evolve-Article-AllowableCOBieValues-01Contact.XLSX