Staff approvals and control.
Your community’s voice, your team’s judgment.
Tools should make the work easier to manage. Decisions about facts, wording, and public information stay with the people responsible for them.
The right help.
In the right hands.
Municiply brings drafting, review, source management, and activity records into a shared workspace. Staff permissions and approval steps keep responsibility visible.
Permissions with a purpose.
The workspace distinguishes what staff can do. Approval permissions belong to authorized team members rather than every person who can draft.
Official information first.
Residents should be directed to confirmed municipal sources. When an answer is missing or requires a decision, the next step is the relevant office.
A record of the work.
Activity records and captured content can support internal review. Staff should confirm exactly what is recorded and what can be exported.
Review the information.
Then decide what’s ready.
Know what is included.
Know what still needs attention.
Live publishing depends on supported, connected accounts. A sandbox or demonstration is not proof of a live channel connection.
Archive capture is automatic for what Municiply publishes, and it is not presented as a complete public-records compliance archive — activity performed directly on a platform is outside what it can observe. Review retention, capture, and export needs with your own records team.
Ask us for the current information your team needs to evaluate access, data handling, hosting, and service scope. This page does not claim an unverified certification.
The phone app and voice experiences are in development or planned, and are labeled that way wherever they appear. The availability table below is the single list, and it is checked against the product rather than against a roadmap.
One table.
Checked against the product.
Four states, and we use them consistently across this site. Available means built and working. Setup required means built, and it needs a connection, a credential or a configuration step before it does anything for you. In development and Planned mean exactly that, and we will not quote you for them as though they were finished.
| Capability | State | What that means for you |
|---|---|---|
| Publishing and channels | ||
| Drafting, approval workflow, scheduling | Available | Staff roles, an approval that locks the content, a re-review when approved wording is edited, and an audit entry for every change. |
| Facebook publishing | Setup required | Built on the Facebook Graph API, with duplicate publication prevented at the database and each publication confirmed by reading the post back. Each page connects individually, and customer pages need Meta’s app review. |
| Emergency pause and immediate publishing | Available | Pause routine publishing, send an urgent notice while it stays paused, then resume with an explicit decision about what came due in between. Enforced in the publishing job, not only in the screen. |
| Instagram publishing | In development | Not built. A post that targets Instagram only is refused by name rather than left sitting in a queue nobody is watching. |
| Google Business Profile · Nextdoor | Planned | No integration exists today. Posts are written with these destinations in mind; nothing publishes to them. |
| Records and archiving | ||
| Automatic archiving of what Municiply publishes | Available | Captured the moment a publication is confirmed. Append-only, with event time and capture time kept as separate facts, a content hash per record, full-text search, and a complete export of whatever a search matches. |
| Archiving of resident comments and of edits made on the platform itself | In development | Municiply archives what Municiply publishes. Activity performed directly on Facebook by somebody else is outside what it can observe until the channel is connected and the platform permits reading it. |
| Reporting | ||
| Monthly reporting | Available | Published counts by channel, failures needing attention, approval turnaround, archive capture. Printable. |
| Reach and engagement figures | Setup required | Read from the platform once a channel is connected. Until then the report says “not available” rather than showing zero. |
| Working with residents | ||
| Community Inbox — triage, assignment, approved replies | Available | The workflow runs and is audited. |
| Reading and sending comments on the platform | Setup required | Needs the live channel connection, and comment ingestion is not built yet either — the queue stands at zero rows and says so rather than showing invented residents. An approved reply is shown as approved and not as sent, because nothing has reached the resident. |
| Virtual Agent | Setup required | Your staff manages the sources, subjects, wording and pause control, and it answers residents within those limits without approving each answer. Installation on your website is a separate step. |
| Resident photo submissions | Setup required | Submission, staff review and permission records are built. Opening it to the public is a configuration decision per municipality. |
| Not built yet | ||
| Phone companion app | In development | Not published to the App Store or Google Play. No download badge until there is something behind it. |
| Voice access (Alexa, Siri, Android) | Planned | Described on its own page as planned. Nothing is live. |
| Broad social listening beyond your own posts | Planned | Only comments on your own posts are in scope, and even those are not read yet — nothing ingests them until a channel is connected live and the platform grants the permission. Monitoring public mentions anywhere else needs a separate data provider and is not part of what you would be buying. |
If something on this site contradicts this table, this table is right and we want to know about the other page.
Captured from the product.
Not drawn for this page.
Every image below is a capture of the running application on the Lindenhurst demo account, taken on 12 November 2026. The content in them is demonstration data, and the captions say so. Nothing here is an illustration of something that does not exist, and nothing in them is a customer result.
Three more screens: the emergency notice, the Community Inbox, and archiving
The specifics.
Not the reassurance.
What follows describes how Municiply is actually built. It makes no certification claim, and it is not legal advice about your own obligations.
Staff roles and approval
Four roles: administrator, approver, creator and viewer. The role is enforced on the server for every action, not by hiding a button — a request that bypasses the screen is refused the same way. Approving locks the content, and a material edit to approved wording returns it for review rather than publishing quietly.
Separation between municipalities
Every record carries the municipality it belongs to, and every query is bound to the municipality on the signed-in session. Stored files are filed under a per-municipality prefix and a request for a file outside your own prefix is refused. A regression test suite exists specifically to keep that boundary closed, and it runs against the real database schema.
Account access
Sessions are server-side records that expire, and removing somebody from your team revokes their sessions immediately rather than at the next expiry. Historical records keep the name of whoever took each action, so removing a person does not erase who approved what. Two-factor authentication is not available yet; password reset by email is waiting on an email provider decision.
Hosting
Cloudflare Workers with Cloudflare D1 for records and Cloudflare R2 for media. No separate server you have to patch. Backups and point-in-time recovery are Cloudflare’s platform capability for those services rather than something Municiply operates itself, and that distinction matters to a records officer, so we state it rather than implying our own backup regime.
Exports, and leaving
Your calendar, published history, post content, media inventory and activity log each export as CSV, and the archive exports as CSV or JSON with its capture metadata attached. Exports are available throughout, not only at the end, and are themselves recorded in the activity log. There is no all-or-nothing archive you have to request from us.
Where AI is used, and where it is not
Drafting runs on a deterministic template engine by default: no external AI provider, no content leaving the platform. Where a municipality opts into AI drafting or document reading, requests go to Anthropic’s API under a key held for that municipality, the usage is metered per municipality, and the documents involved are the ones your staff uploaded. The Virtual Agent is a separate system that Municiply configures rather than hosts, and Municiply stores none of its conversations.
Retention and legal hold
A retention term and a legal-hold flag are recorded and shown. Neither deletes anything: the archive is append-only and nothing in the product purges it. We say that plainly because a retention setting that silently destroyed records would be far worse than one that does nothing. Disposal under your jurisdiction’s schedule is a conversation to have with your records officer, and we make no compliance claim.
What a content hash is and is not
Each archive record carries a SHA-256 hash of what was captured, which makes two captures of the same wording visibly the same and makes a later alteration detectable. It is tamper evidence. It is not proof of immutable storage, and we will not describe it as such.
Bring your questions. We’ll work through them.
Include your IT, records, or procurement team when the time is right. The scope should be clear before you move forward.