Value maps: the code tables behind clean integrations

Every system in city hall has its own codes. The 311 system says "Public Works"; the finance system wants PW. The permitting system's status is "Issued"; the open-data portal expects "Active". The agenda system names a board "Parks & Recreation"; the records repository files it under a folder ID.

Integrations live or die on these translations. Done badly, they're scattered across scripts and nobody can find them. Done well, they're a value map: one small table, kept in one place.

What a value map is

A value map is a code table with two columns: what the value is in one system, and what it should become in another.

Public Works       -> PW
Code Enforcement   -> CE
Parks              -> PRK
Utilities          -> UTL
Sanitation         -> SAN

That's it. The power comes from where it lives and how it's used, not from its complexity.

Why not just write the translation into the flow?

You can, and many scripts do. The problems arrive later:

• The same table gets copied. Three flows each have their own department list, and only two get updated when a department is renamed.
• Nobody outside IT can see it. The finance analyst who knows the codes can't read a script.
• Changes need a developer. Adding one board or one status code becomes a ticket.

A value map that every flow refers to fixes all three. Update it once, and every flow uses the new value on its next run.

Decide what happens to unknown values

The most important setting on a value map isn't an entry. It's what happens when a value isn't in the table. There are three sensible choices:

• Keep the original value. Fine when the destination accepts free text.
• Use a default. For example, any unknown department becomes GEN (general). Good for reporting codes where something is better than nothing.
• Fail the record. The record is marked invalid and set aside for a person to look at. Best when a wrong value would cause real harm.

Where value maps show up in city work

• Department and fund codes between 311, work orders and finance.
• Status codes between permitting and the public dashboard or open-data portal.
• Board-to-folder maps for filing agendas and minutes in a records system.
• Request types to crews, so potholes go to streets and tree limbs to parks.
• Per-municipality settings, where one shared flow serves several cities, each with its own map.

Value maps alongside other rules

Code translation usually travels with cleanup. A typical clean-and-check step does several things in order:

The 311 triage template is a good example. It collapses extra spaces in the description, copies the department name into a new field, translates it through the "Department codes" value map with a default of GEN, then checks that each request has an address and a map location.

One flow, many agencies

Value maps matter even more when one flow serves several agencies. A county IT team or a service provider can build the flow once, and each city fills in its own map of departments, boards or folders. The flow's logic stays shared and tested; only the local codes differ.

Keeping value maps healthy

• Give each map an owner. Usually the person who owns the destination system's codes.
• Describe it. One sentence saying what it translates and which flows use it.
• Review unknowns. If records fail for unknown values, that's the map telling you it needs a new entry.
• Track changes. Who changed a code, and when, matters during an audit.

In SentraBridge

Value maps are part of each client's workspace, managed alongside connections and flows. The Apply rules step uses them, with a choice of keeping the value, using a default, or failing the record to the Invalid output.

Because each city, county or district has its own workspace, a shared template can rely on a map that every agency fills in for itself, and changes to it appear in the activity log.