Skip to main content

Individual facility editing

The feature dashboard's Relationships tab opens the Edit Feature Relationships dialog — the per-feature surface for two related questions: which other features is this one related to, and which relationship groups does it belong to. Use this when you have a small number of changes or are correcting a one-off mistake during diagnostic work. For the click-by-click flow, see Feature relationships.

Learning objectives

By the end of this lesson you should be able to:

  • Use the Edit Feature Relationships dialog to mark related features and toggle group memberships
  • Recognize that relationship codes come from the group matrix, not the per-feature dialog
  • Decide when per-facility editing is enough vs when to graduate to relationship groups
  • Record a relationship submittal note for each direction of a pair

What the dialog does​

The Edit Feature Relationships dialog has two halves:

Top — Add or remove related features. A filterable table of every other feature in the project, with a checkbox per row. Checking a row will add the opposing feature to the relationships tab for editing; unchecking removes the feature and any relationship information associated. Filter by name to narrow the list, or use the Add All / Remove All buttons to operate on every visible row at once. The In Violation column reads Yes for any feature the latest analysis found in violation with this one, in either direction — hover over it to see which criteria — so you can spot the pairs most likely to need a relationship.

Bottom — Relationship groups for this feature. A chip list of every relationship group defined in the project. Click a chip to toggle membership in that group. The feature-count on each group updates as you toggle.

The dialog is bidirectional: adding a relationship from feature A to feature B simultaneously adds it from B to A.

warning

Adding a Relationship Group to a feature does not automatically build all relationships associated with that relationship group. See Relationship Groups for more information.

Editing the relationship​

Once the relationship is added to the listing in the relationship tab, the specific relationship code and barricade status for that specific PES -> ES pair can be edited. Any relationship code edited manually in this way will be marked as "user-overridden" and will not be modified by the automated build-relationships tool in the Relationship Groups editor.

The Barricaded dropdown reads Segments until you choose Yes or No. Segments means the pair follows the barricaded flags on the two facilities' Segments tabs; Yes or No overrides them for this pair, in both directions. The build never touches the barricade value, so it needs no override lock. See Barricading in Siter.

The Relationships tab also carries an In Violation column, so after re-running analysis you can filter to Yes and see which pairs still violate without leaving the tab.

Documenting a pair with a relationship note​

A relationship code tells the engine how to treat a pair; a relationship submittal note tells the reviewer why. The note is free text attached to one direction of the pair — one facility as the PES, the other as the ES — and prints on the submittal forms directly under that pair's row (see Forms).

Each pair has two independent notes. On the Relationships tab, the Note column's button expands both under the row: A → B (this facility as the PES) and A ← B (the other facility as the PES). Both directions are editable from either facility. Notes are not criteria-specific: one note per direction serves every criteria in the project and prints on every standard's form the pair appears on, so a mitigation that applies under only one criteria should name that criteria in the note text. The relationship build never adds, changes, or removes them — so a note you write survives every rebuild and every Reset All Relationships.

Use a note when the relationship or barricade choice is not self-evident from the form: a shared operation that justifies sameline, a berm that justifies the barricade flag, or a pair accepted under a waiver. To write the same note on many pairs at once, select them and use Copy to Selected, or add notes in bulk from the analysis results. For the click-by-click steps, see How to add a relationship submittal note.

When per-facility editing is enough​

Per-facility edits are appropriate when:

  • You have a handful of pairs to define
  • A relationship is unique enough that no group abstraction fits (This parking lot exclusively serves this PES)
  • You are correcting a one-off mistake during diagnostic work

For everything else — especially when many facilities share the same operating-line context — graduate to relationship groups. Per-facility editing in a project with dozens of related pairs becomes brittle quickly, and the matrix lets you author a clean structure once instead of editing pairs N times.

Try it​

In a project with a violation between two facilities that should be related:

  1. Open the feature dashboard for one of them and click into the Edit Feature Relationships dialog
  2. In the top half, check the row for the other facility
  3. In the relationship tab of the feature dash, modify the assigned relationship
  4. Confirm and re-run analysis — verify the violation either disappears or shifts under the new Exposure Type
  5. Expand the pair's note and write one sentence in the direction you changed explaining why the pair is related, then save and generate the submittal form to find the note under the pair's row