Using Project Info as an editable lookup table — a practical example

Mathias Jonathan — Tue, 02 Jun 2026 12:40:52 GMT

Hi everyone,

Here's a technique I've been thinking about for a while: using the Project Information fields as a lightweight, human-readable database that any team member can update without touching the property expressions themselves.

The idea is simple: you store your lookup data as a plain text string in a Project Info property, using a consistent separator (here: !!) to mark the end of each value. Then, property expressions parse that string on the fly.

— The technique, step by step —

1. Store your data in Project Info

Create a Project Info property (e.g. ABBREVIATION - DO NOT MODIFY) and fill it like this:

Sanitary: SAN.!! Bedroom A: BED.!!

Each line follows the pattern: Key: Value!!
The !! acts as a right-hand delimiter. The newline is optional but helps readability — ArchiCAD ignores it in expressions.

2. The expression

This expression reads the Zone Name and returns its abbreviation if one exists, or falls back to the original name (I made the expression in the rench version of archicad, Zone/ Nom de Zone is the french version of room name):

IF (CONTAINS (CONCAT ( {Property:Zone/Nom de Zone}; ": " );{Property:ProjectInfoPropertyDefinitionGroup/ABREVIATION-DO NOT MODIFY} );SPLIT (SPLIT ({Property:ProjectInfoPropertyDefinitionGroup/ABREVIATION-DO NOT MODIFY}; CONCAT ( STR ( {Property:Zone/Nom de Zone} ); ": " );2);"!!";1);{Property:Zone/Nom de Zone} )

3. What the expression does — step by step

Step 1 — CONTAINS : does a match exist?

CONTAINS ( CONCAT ( {Zone Name}; ": " );{Project Info string} )

Checks whether the Zone Name followed by : appears anywhere in the Project Info string.
→ If FALSE: the zone has no abbreviation → return the Zone Name as-is (the last argument of IF).
→ If TRUE: proceed to extract the abbreviation.

Step 2 — First SPLIT: isolate everything to the right of the key

SPLIT ( {Project Info string}; CONCAT ( {Zone Name}; ": " ); 2 )

Splits the full string at "Zone Name: " (using CONCAT to add the 🙂 and returns part 2 (everything after the key).
Example: from "Sanitary: SAN.!! Bedroom A: BED.!!" → "SAN.!! Bedroom A: BED.!!"

Step 3 — Second SPLIT: cut off at the !! delimiter

SPLIT ( [result of step 2]; "!!"; 1 )

Splits at !! and returns part 1 (everything before the first !!).
Example: "SAN.!! Bedroom A: BED.!!" → "SAN."

That's the abbreviation — clean and ready to use.

— Why this approach is useful —

The lookup table lives in Project Info, not buried in an expression. Any team member can update it.
Only one thing to reserve, works even with modules.
The expression itself never needs to change when you add new entries.
The same logic works for any key→value substitution: room type codes, material abbreviations, etc.
The !! delimiter is visually distinctive and unlikely to appear in real room names (You can change the delimiter if you want).
You can go to a new line between entries for readability — it doesn't affect parsing.

The more complex variant (checking whether a zone's area falls within a min/max range per typology) follows exactly the same logic — I'll post that separately if there's interest.

Hope this helps!

Operating system used: Mac Apple Silicon

topic Using Project Info as an editable lookup table — a practical example in Project data & BIM

Using Project Info as an editable lookup table — a practical example