A Granicus portal update is not the jurisdiction's official notice record

Start with the jurisdiction's notice authority

The direct operating rule is simple: a portal message is service information until the jurisdiction can show that it satisfies the controlling notice requirement for the named action. The case record should identify the jurisdiction, department, proceeding, decision or deficiency, legal or adopted authority, recipient population, authorized issuer, approved template and language, required contents, permissible channels, service rule, response or appeal period, and the version effective on the event date. A product's ability to post a status or send a message does not decide whether the notice is legally operative.

Different events can require different records. A completeness request, plan-review comment, hearing notice, permit issuance, inspection correction, code-enforcement order, fee invoice, expiration warning, and appeal decision may share a portal but carry different signers, recipients, service methods, public-record rules, and consequences. The operating design should name each event precisely instead of treating every update as a generic permit-process notification. If qualified legal or records review has not established the applicable rule, the system should preserve the communication without labeling it statutory or official service.

Preserve creation, delivery, and service as separate events

The notice chronology should retain the case and notice identifiers, source decision, author, approver, template and content hash, attachments, recipient and address source, language and accessibility accommodation, channel, issue time, delivery-provider identifier, dispatch result, bounce or return, portal availability, recipient access when observable and appropriate, alternative service, corrected notice, withdrawal, and the rule used to calculate the next deadline. Creation proves only that a record was produced. Dispatch proves only that a channel accepted it. Portal access proves neither receipt nor legally sufficient service unless the applicable authority says so.

The public-facing status should also remain distinct from the internal case state. Staff may correct a typo, replace an attachment, reopen a task, or change a due date after an update was exposed. Those actions require an append-only history that shows what the recipient could see at each relevant time. The system should never rewrite an earlier notice and leave the audit trail looking as if the corrected version was the one originally served.

Design for failed, disputed, and multi-channel service

A jurisdiction should test an inaccessible attachment, invalid email address, shared applicant account, returned mail, language request, representative change, late address correction, duplicate recipient, portal outage, and a notice that must be posted or published outside the portal. The workflow should route each failure to an accountable owner, preserve the unsuccessful attempt, issue an authorized replacement where appropriate, recalculate deadlines only under the controlling rule, and present a clear corrections or appeal path. Operational convenience cannot erase the difference between a communication attempt and completed service.

The Open311 specification is useful adjacent context because it makes service-request identifiers and status exchange visible, but it does not create authority for a permitting, licensing, inspection, or enforcement notice. Portland's AMANDA contract record shows one local government maintaining a named platform relationship. It does not establish another jurisdiction's adoption, configuration, notice law, accessibility conformance, record retention, or service outcome.

Audit the notice record, not the portal label

A representative acceptance test should issue one ordinary notice, one notice with a corrected attachment, one multi-recipient notice, and one notice whose first delivery fails. Reviewers should be able to reconstruct the effective authority, approved content, recipients, channels, attempts, service conclusion, deadline calculation, staff actions, public view, retention state, and any later appeal without relying on a screenshot or a current status label. Metrics should distinguish messages created, dispatched, delivered, returned, corrected, disputed, and legally treated as served under the named rule.

Granicus' official page establishes current provider positioning for digital permitting, licensing, self-service, communication, and mobile workflows. It does not prove a buyer's configuration, adopted notice rule, legal sufficiency, accessibility, delivery, record integrity, service timeliness, approval, or public outcome. Jurisdictions retain responsibility for authority, due process, notices, accessibility, language access, public records, privacy, security, deadlines, appeals, and lawful professional judgment.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Civic Permit Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.