Decidim citizen initiatives module: who needs it and what it takes
The citizen initiatives module is optional. It adds initiative spaces on top of an existing Decidim installation, so residents can launch petitions and gather support on a platform your public body runs in its own infrastructure. A public body or civic team usually considers it when it already runs Decidim for processes, assemblies or proposals and wants a formal, public route for residents to put a topic before the organization. Before any build work, the team should decide whether the module fits how the organization already handles petitions, public comment and formal responses to residents. The rules are a policy decision before they are a configuration task. Legal counsel, the clerk or secretariat responsible for public records, and the owner of participation policy should agree on who may start an initiative, what supports a proposal must gather, how supports are checked, and what the organization must do once a threshold is reached. The platform team then translates those decisions into settings. If the rules are still open when the build starts, the configuration will change during testing, and that rework is where most schedule slippage tends to come from.
Signature, verification and threshold rules are the specifics you must confirm before you commit to a design. This section does not state the signature windows, verification options, minimum support counts or acceptance logic that the module applies. Check the Decidim documentation for the exact version your installation runs, because these behaviors can change between releases. Decidim's current security policy supports only the two most recent minor lines, currently 0.32.x and 0.31.x, so an installation on 0.30.x or earlier needs an upgrade plan first. Decidim's update guide asks teams to move one minor version at a time and to back up the database before each step, which affects when the initiatives work can realistically begin. Write the confirmed rules into a single specification that names each setting, its owner and the evidence the organization will keep. Ask the implementer to show, in writing, which parts of the rules are standard Decidim behavior, which need custom work, and which would need a change to the legal process. Any gap between the written policy and the configured behavior should be closed or formally accepted before launch, because residents will rely on the outcome of an initiative and the organization will have to explain it publicly.
Identity is the control that most affects whether an initiatives module is trusted. Decidim includes identity verification and authorization systems that let an organization restrict actions such as signing to verified participants. Decide early which verification method residents will use, how it connects to the organization's existing identity sources, and whether social login providers such as Google or Facebook are acceptable for people who sign petitions. Each choice affects data protection obligations, accessibility of the sign-up path and support load for residents who cannot complete verification. Plan the operational checks before launch. Confirm that outgoing email for confirmations works through your SMTP service, that background jobs run reliably in production, and that file storage and backups cover the initiative records. Run a test initiative from start to finish with staff acting as residents, including a signature that should be rejected, a duplicate attempt and a threshold being reached. Record the results, because they become the evidence your team and any auditor will ask for.
What the Decidim citizen initiatives module does
The initiatives module adds petitions to Decidim's participatory spaces, with signature collection, signer verification and progress tracking toward acceptance. Each function below can be tested in a staging instance before launch. Confirm the exact screens, options and defaults for the Decidim version you deploy, because these change between releases.
Initiative creation in participatory spaces
Residents start an initiative inside a Decidim participatory space, so the petition sits alongside the processes, assemblies and components the organization already runs. Check which roles can create initiatives, whether a new initiative needs a review step before it is published, and which fields the form requests. Test the flow end to end with an ordinary participant account, since permissions set at the space level decide who sees the create action. Confirm the creation steps and defaults in the module documentation for your version.
Online signature collection
Participants add their support to an initiative on the platform, and each signature is recorded against the account that gave it. Test that one account cannot sign the same initiative twice, and that the public counter updates after each signature. Confirm whether signatures can be withdrawn and under what conditions, and what the signer sees at each step. Ask your team to decide whether signing requires verification, because that choice drives the design of the verification card below.
Offline and mixed signature collection
Paper or in-person signatures must join the online record before the acceptance threshold is evaluated. Decide who transcribes sheets, how entries are checked against the signer's identity, and how original paper is kept under your records policy. Mixed collection carries the highest data-handling risk because personal data moves through a manual step. Confirm whether your version supports offline entry in the interface, through an import, or only through an administrator action.
Signer verification through authorization
Decidim's authorization system lets the organization limit actions such as signing to participants who passed a check. Choose the verification method before launch, such as an identity provider or a document check, because it determines who can sign and how much personal data the platform stores. Test rejected, expired and duplicate verifications, and confirm that one verified identity cannot back several accounts under your rules. List the authorization handlers available in your version and their configuration options.
Thresholds and progress toward acceptance
An initiative moves toward acceptance once it reaches the signature threshold set for it, and the page shows progress against that number. Confirm who sets the threshold, whether it can differ by initiative type, and what happens when collection closes below it. Test the counter on a staging dataset with known totals, including offline entries and removed signatures. Write the exact acceptance rule into your governance documents so administrators, auditors and residents read the same logic.
Signature and threshold choices for the Decidim citizen initiatives module
This table compares the main configuration choices for the initiatives module: how signatures are collected, how strictly signers are verified, who reviews an initiative and how acceptance thresholds are set. Read each row against your legal or policy framework first, because that framework often settles the answer before the software does. Confirm each setting in your installed version before you promise residents a process.
| Decision and option | When it fits a public body | What it asks of staff or residents |
|---|---|---|
| Signature collection: online only | Residents sign through the platform. Fits bodies where most residents have accounts and online collection is lawful. | Residents need an account and a verification step. Staff watch signature counts and handle support requests. |
| Signature collection: offline only | Signatures are collected on paper or in person. Fits bodies whose rules accept paper or where many residents lack reliable online access. | Staff need an intake procedure, data entry checks and a documented match between each paper signature and a verified person. |
| Signature collection: mixed | Online and offline signatures count toward one total. Fits bodies that want online reach and must still accept paper. | Staff must prevent double counting across channels and document both paths. Confirm how the module detects duplicate signers. |
| Verification level for signers | Sets the authorization a signer must pass before a signature counts. Fits bodies whose rules name an identity standard or residency requirement. | Residents complete the chosen check. Staff configure the authorization workflow and handle failed checks. Confirm which handlers your version provides. |
| Reviewer of initiatives | A designated officer, committee or administrators check eligibility before an initiative proceeds. Fits bodies that separate platform administration from eligibility decisions. | Reviewers need defined roles, an eligibility checklist and a timed response. Confirm whether review steps are recorded. |
| Acceptance thresholds | The signature count and any other conditions are set per organization from the governing framework. Fits any body, since each level of government may differ. | Take values from your legal or policy framework. Confirm how the module stores them and logs later changes. |
How a petition moves from launch to acceptance
A Decidim initiative moves through a sequence of stages, and the states, transitions and roles that define those stages come from the installed version and your configuration. Map each stage to a decision before you design the process. A resident or group starts by creating an initiative in the initiatives space and completing the fields the configuration requires, such as title, body, scope and any supporting material. The initiative stays in a pre-submission state until its author sends it on. From there, the configured review applies. Depending on your setup, administrators or a designated group check the content before signature collection opens. Confirm which states exist in your version, which roles can move an initiative between them, and which transitions send notifications to the author, reviewers and signers.
Signature collection is where the channel decisions matter most. Decidim initiatives can gather signatures online, offline through paper or in-person forms entered by staff, or through a mix of both. Each channel needs its own rules. You need to decide who may record offline signatures, how paper forms are entered and checked, how duplicates across channels are caught, and whether offline signatures count toward the same threshold as online ones. Confirm how the installed version records the channel on each signature and whether exports and reports separate online from offline totals. Those reports will be the basis for any public or audit-facing count, so test them early.
Authorization is the gate for signing. Decidim includes an authorization system that lets an organization restrict actions to verified participants, and for initiatives this is where a signature is permitted or refused. The organization chooses which verification method applies, and the options depend on the handlers shipped with the installed version and any custom handlers you add. Confirm which handlers can be attached to signing in your version and whether they can be required per initiative or only globally. Decide when verification happens: at account creation, at the first signature, or for each initiative. That choice affects drop-off among residents and the support load on your staff.
Acceptance depends on the signature threshold set in configuration, counted from signatures that passed verification within the configured collection period. Confirm how the installed version treats duplicate signatures, signatures later invalidated, and offline records awaiting validation. Then decide who certifies the final count, how the outcome is published, and what happens to an initiative that falls short. Before launch, run the full path in a staging environment with test accounts, including a rejected case and a case that passes only after offline signatures are added. Label those test results as illustrative in your project records, and verify each transition and notification against your own process document.
Implementation sequence from installation to first live initiative
This sequence takes a Decidim instance from a confirmed supported version to a first published citizen initiative. Each step closes with a record the client keeps, so the organization can see what was decided, tested and approved before residents can sign anything.
Confirm the Decidim version and support status
Before any installation work, confirm which Decidim release line the organization will run. Decidim supports only the last two minor versions with security updates until version 1.0, which currently means 0.32.x and 0.31.x, so older branches need an upgrade plan first. Check the Ruby, Node and PostgreSQL requirements for the chosen branch, and confirm the security contact and patch windows in the project's security policy. The output is a version decision record that names the target release, its support status, its runtime requirements and the owner who accepts them.
Install or upgrade the platform
Install Decidim as a Rails application or with Docker in the client's own environment, or upgrade an existing instance one minor version at a time. Upgrades must follow each release's instructions because some change database structures, and the database must be backed up before any change. DeployOpen configures background jobs, file storage, SMTP, maps and geocoding, and social login providers at this stage, as production setups require. The output is a installed environment record listing versions, hosts, the backup taken before any change and the restore test result.
Enable the initiatives module
Turn on the optional initiatives module for the organization and confirm that its space and related components appear in the admin interface as expected. Decide which organizations or spaces will host initiatives if the instance serves more than one. Verify the module on a non-production copy before changing the production configuration, and check that public pages and admin menus render without errors. The output is a configuration record showing the module state per organization, the date it was changed and the name of the person who approved the change.
Configure authorization and verification
Decide who may create, support and sign an initiative, then configure the identity verification and authorization workflows that enforce those rules. Decidim includes flexible authorization so organizations can restrict actions such as signing to verified participants. Map each action to a verification method, confirm which identity providers are used, and document how a resident who cannot complete verification is handled. The output is an approved authorization rule set, signed off by the legal or governance owner, with a test account matrix showing which role may perform which action.
Set signature channels and thresholds
Define how signatures will be collected: online, offline on paper or in person, or a mix of both. For offline collection, decide how paper forms are verified, entered and linked to the initiative record. Set the acceptance thresholds and any rules on timing or geography with the governance owner, because the threshold rules are a policy decision, not a technical default. Confirm the exact threshold and deadline settings for the chosen version in the official documentation before publishing them. The output is an approved rule set covering each channel, each threshold and the audit trail for offline entries.
Configure email and file handling
Set up outgoing email through SMTP so confirmation messages, moderation notices and status updates reach residents, and confirm the sending domain and bounce handling with the email team. Configure file storage through ActiveStorage for supporting documents and signature exports, and set upload restrictions such as file types and sizes according to the organization's data handling policy. Test each path with real files and messages in staging. The output is a test log showing successful sends, uploads, downloads and deletions, along with the storage and retention settings used.
Test with a staging organization
Create a staging organization that mirrors production settings, and run the full initiative lifecycle in it: creation, review, publication, online signing, offline entry, verification, threshold checks and closure. Use test identities for each authorization role and record every result, including failures and the fixes applied. Repeat the key tests after any configuration change or upgrade. The output is a signed test log listing each scenario, its expected result, its actual result and the retest outcome, which the governance owner reviews before go-live.
Train moderators and publish a first initiative
Train the moderators and administrators who will review initiatives, handle verification exceptions and process offline signatures. Give them a written runbook covering the approval steps, escalation contacts and the security reporting route described in the project's security policy. Publish one initiative in production under the agreed rules, then watch the first signatures, notifications and audit entries closely. The output is a training attendance record, the approved runbook and a published initiative record that the organization can point to as the first live result.
What drives effort and cost on the initiatives module
This table compares the main effort and cost drivers for the Decidim initiatives module. For each driver it shows who pays for the work, whether the cost is one-time or recurring, what makes it grow, and how to keep it down. Scope, timing and price follow from a written scope agreed before work starts, so use the table to prepare questions for a quote.
| Driver | Who pays and cost type | What increases it | How to keep it down |
|---|---|---|---|
| Number of organizations or languages | Client and implementer pay for one-time setup; translations recur with new content | Each extra organization, locale or branded theme repeats configuration and testing | Agree locales and shared settings in the written scope before build starts |
| Legal rules for signatures | Client's legal team defines rules; implementer configures them one-time, and changes recur | Thresholds, signature windows, eligibility by municipality or age, and rule exceptions | Get the rule set signed off in writing before design and keep rules as configuration |
| Identity verification integrations | Client pays identity provider contracts; implementer builds the connector one-time | Each provider, data-matching logic, and fallback paths for failed checks | Confirm which authorization methods your Decidim version supports and reuse existing verification |
| Offline signature handling and data entry | Client staff or contractors pay for data entry; implementer builds the import one-time | Paper volume, scanned form formats, duplicate checks, and verification of each entry | Standardize one paper form and agree duplicate and verification rules before collection starts |
| Custom reporting | Implementer builds reports one-time; client maintains them on a recurring basis | Number of audiences, export formats, and reports tied to legal submission | List required reports in scope, start from standard exports and extend only the gaps |
| Existing data migration | Implementer builds the import one-time; client validates source records | Number of source systems, record quality, historic signatures and identity linkage | Profile source data first and confirm which closed initiatives can be migrated under your rules |
| Staging and load testing | Implementer runs tests; client provides staging infrastructure, typically per release | Expected signing peaks near deadlines, number of environments, and repeated test cycles | Build a test profile from expected peaks and reuse test scripts across upgrades |
| Staff training | Implementer delivers sessions one-time; client absorbs staff turnover over time | Number of roles, staff turnover, and verification and moderation procedures | Train by role, record procedures as runbooks, and plan refresher sessions at upgrades |
Data setup and identity verification before the first signature
Before the first petition opens for signatures, four data sources and one policy decision must be settled. The initiatives module depends on resident accounts inside the Decidim organization, a verification or authorization method that tells the module whether a signer is eligible, storage for supporting documents, and outgoing email for confirmations and status notices. The policy decision is the signer identity standard: what counts as proof that a person is a valid signer for a given initiative. Decide that standard with legal and security staff before you import any signer list, enable signature collection, or announce a launch date. Every later setting depends on it, and changing it after signatures exist is difficult to explain to residents.
Start with accounts and login. Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login out of the box. These providers can be configured globally for the platform or per organization, and any other OmniAuth strategy can be added as a custom provider. Each option answers a different question. A social login shows that the person controls an account at that provider, which may be enough for some participation actions but is weak evidence of residence. If your rule requires a national eID, a municipal register or a government identity service, plan that integration as a custom OmniAuth strategy and test it in staging before the module opens. Ask legal which providers are acceptable for signing, and record the answer in the decision log.
Next, define how verification feeds the signer record. Decidim includes identity verification and authorization systems that let an organization restrict actions such as signing to verified participants, so the module can check eligibility before a signature is accepted. Write down exactly which attributes the verification step returns, which ones the platform stores, and which ones it discards. Decide how long signer data is kept, who can query it, and whether exports to a records office are included. Ask your security team how the PostgreSQL database holding those records is encrypted, who can read it, and which backups contain it. Keep the data set as small as the signature rule allows, and document the reason for every field that remains.
Finally, configure the supporting infrastructure that production installs need. Decidim's production setup covers background jobs through ActiveJob, file storage through ActiveStorage and transactional email through SMTP. Supporting documents for an initiative, such as the draft text, statutes or an organizer's statement, are stored through ActiveStorage, so confirm the storage backend, who can download uploads before publication, and how uploaded files are scanned. SMTP sends signer confirmations and status updates, so ask your mail team to verify sender authentication for your domain and check that no message reveals the full signer list. Run a staging launch with test accounts across each login provider and each email path, and keep the results alongside the signer identity decision.
How the initiatives module connects to identity, email and storage
The initiatives module depends on the same platform services as the rest of Decidim: login providers, verification, background jobs, file storage, email and, where locations matter, maps. It also sits inside a participatory space, so its links to other components must be planned before the first petition is created.
Social login and custom OmniAuth providers
Decidim ships with Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login, configurable globally or per organization, and any other OmniAuth strategy can be added as a custom provider. Initiative signers and promoters sign in through these providers, so each one must be enabled for the right organization and tested end to end. Confirm which providers your residents can legally and practically use, and who owns the client credentials and callback URLs in your environment.
Identity verification and authorization
Decidim includes identity verification and authorization systems that let an organization restrict actions such as signing to verified participants. For initiatives, this decides whether a signature counts toward the acceptance threshold. Confirm which verification workflows your legal framework requires, which authorization handlers you will configure, and how verified data is retained and deleted. Ask your team to document who approves verification exceptions.
Background jobs through ActiveJob
Signature confirmations, notifications and other deferred work run as ActiveJob tasks. A production setup needs a configured queue backend and worker processes that run continuously, or confirmations and notices will queue without being sent. Confirm the queue adapter, worker count, retry behavior and monitoring in your target environment, and test a signing spike to see whether the queue keeps up.
File storage through ActiveStorage
Attachments such as initiative documents and images are stored through ActiveStorage. The storage service you choose determines where petition material lives, how it is backed up and how it is restored with the database. Confirm the storage service, encryption at rest, access controls on direct URLs, and whether backups capture both the database and the stored files so that records stay consistent after a restore.
SMTP for confirmations and notices
Signature confirmations, promoter notices and review messages depend on outbound SMTP. Mail that fails silently can break the signature flow, since residents may never confirm their support. Confirm the SMTP relay, sender domain, SPF, DKIM and DMARC records, bounce handling, and the email templates that must carry your organization's legal wording. Send test messages to providers your residents actually use.
Maps and geocoding for locations
If initiatives collect a location, such as a neighborhood or a district, the maps and geocoding services must be configured. Geocoding usually calls an external provider, which means personal location data may leave your environment. Confirm which provider is permitted under your data protection rules, what coordinates or addresses are stored, and whether a self-hosted geocoder is required. Decide whether location is mandatory for acceptance.
Links to proposals and participatory spaces
An initiative must sit inside a participatory space such as a process or assembly, and it may reference proposals or other components. These links decide who can see the initiative, which permissions apply and how results appear in reports. Confirm which space will host initiatives, how the initiatives component is enabled there, and how proposal links are created and moderated before go-live.
Keeping the initiatives module supported through Decidim upgrades
The initiatives module is an add-on, so every Decidim core upgrade is also a compatibility decision for it. Start by confirming which release line each environment runs. Until Decidim reaches version 1.0, the project supports only the last two minor versions with security updates. At the time of the supplied facts, that means 0.32.x and 0.31.x, while 0.30.x and earlier receive no security updates and leave a deployment exposed. Check the current supported list in the project's SECURITY.md before you plan, because the window moves as new minor releases ship.
Upgrade one minor version at a time. Moving from 0.29 to 0.31, for example, means passing through 0.30 with its own upgrade steps. Follow each release's upgrade instructions, because some releases change database structures, and the tables that store initiatives, signatures and verification records are part of that schema. Back up the PostgreSQL database before every step, and confirm that the backup restores into a separate environment. Record the sequence of versions and dates in your change log so that an auditor or incident responder can see which release ran when.
Module compatibility is the check most likely to block an upgrade path. Before you upgrade, confirm that your initiatives module version supports each target Decidim release, and repeat the check for every hop in the sequence, not only the final one. Review the runtime requirements for each target as well. The supplied installation notes list Ruby 3.4.7 and Node 22.14.x for v0.32, and Ruby 3.3.4 with Node 22.14.x for v0.31. Test the full sequence in a staging copy with production-like data, and include the signature collection and verification flows in that test.
Security patches run on deadlines you should plan around. Decidim gives implementers a grace period of 2 months to apply patches for standard vulnerabilities and 4 months for critical ones, measured before details are disclosed. Build a standing change window so that a patch can move through staging and production inside those periods without an emergency change. Report suspected vulnerabilities to security@decidim.org or through GitHub Security Advisories, and name one owner who watches the release feed and decides within days whether an out-of-cycle upgrade is needed. Because the grace period ends at disclosure, keep a current record of the version in each environment so exposure can be judged quickly.
Questions buyers ask before hiring help with the Decidim initiatives module
How much does Decidim initiatives module implementation cost?
DeployOpen does not publish a price list, and a quote follows from the written scope. The main cost drivers are the signature channels you choose (online, offline or mixed collection), the identity verification method, the number of legal thresholds and initiative types, the languages you need, integrations with existing registries or identity providers, and the hosting environment you run in your own infrastructure. One-time costs cover scoping, configuration, custom work, testing and handover. Recurring costs cover hosting, monitoring, security patching, minor-version upgrades and any support retainer. Ask each quote to itemize these workstreams, state assumptions about signature volumes and verification steps, list exclusions, and explain who holds the work products. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How long does an initiatives module rollout usually take?
Duration depends on scope, and no single timeline fits every public body. The schedule is usually set by decisions outside the code: approving the legal rules for signature thresholds and initiative types, choosing the verification method, designing the offline collection and reconciliation process, and confirming who signs off each stage. Technical work adds time when you need custom integrations, a new hosting environment, or migration of existing signatures. Access to cloud accounts, DNS, SMTP and staff reviewers also sets the pace. Ask for a timeline tied to written milestones, with the client dependencies named and a review point after staging tests. Treat any early estimate given without a written scope as provisional.
What must our organization provide before implementation begins?
Most delays trace back to missing client inputs, so confirm these before the scope is signed. Provide the legal rules that govern citizen initiatives, including who may launch one, the signature thresholds, deadlines and acceptance criteria. Name the verification method and the staff who approve it, plus the data protection owner who reviews how identity data is stored. Assign a product owner, a legal reviewer, a communications lead and an operations contact with authority to decide. Grant access to the hosting environment, such as cloud accounts or data center network segments, along with DNS, SMTP, file storage, maps and any identity provider you require. Supply sample initiatives and a test population for staging, and agree who holds administrator credentials and how they are rotated.
Can our own staff implement the Decidim initiatives module alone?
Yes, if your team has the skills and capacity to run the work end to end. Decidim is free and open-source under the AGPL-3.0, and its documentation covers manual Rails installation and Docker. Production work also requires Ruby on Rails and PostgreSQL administration, background jobs, file storage, email delivery and social login configuration where you use it. The harder parts are often non-code: writing configuration that matches your legal rules, designing offline signature reconciliation, testing verification edge cases, and documenting the process for auditors and staff. Consider whether your team can absorb security patching, since the project gives implementers two months for standard vulnerabilities and four months for critical ones before details are disclosed, plus regular minor-version upgrades. A split model, where internal staff own the rules and operations while an outside team builds and tests, is also possible. Decide after a skills inventory.
How do Decidim upgrades affect the citizen initiatives module?
Upgrades can change database structures and module behavior, so plan each one as a tested change. Decidim's update guide says to move one minor version at a time, for example 0.29 to 0.30 before 0.31, to follow each release's upgrade instructions, and to back up the database first. Security support currently covers the 0.32.x and 0.31.x branches, and 0.30.x and earlier are not supported, so an older initiatives setup may need a staged upgrade path. Test signature counts, verification flows, email notifications and any custom code in a staging copy with production-like data before cutover. Confirm the Ruby and Node requirements for each target version, since v0.32 requires Ruby 3.4.7 and v0.31 uses Ruby 3.3.4. Ask any implementer for an upgrade plan that includes a rollback point and a post-upgrade check of the initiatives workflow.
Does DeployOpen certify that our initiatives process is compliant?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Whether an initiative process meets your legal obligations is a question for your legal counsel and the authority that governs it, and the module's configuration must match those rules. If an assessor or regulator expects a named control catalog, confirm which one applies before scoping. For example, NIST SP 800-53 Revision 5 is the federal control catalog, and its SP 800-53B baselines select 149, 287 and 370 controls and enhancements for the low, moderate and high baselines, so a US federal body may map its evidence to that catalog. Ask the implementer to show how each control mapping is produced and where evidence is stored, and ask your assessor to confirm acceptance before work starts.
How are signatures verified and thresholds enforced in Decidim?
Decidim includes identity verification and authorization systems that let you restrict actions such as signing to verified participants, and you set thresholds to match your legal rules. Define the verification method first, including which proof is accepted, how it is recorded, and who can revoke it. Configure the threshold and deadline for each initiative type, then test the edge cases: duplicate signatures, signatures received after the deadline, withdrawn support, and paper forms entered later. For offline or mixed collection, add a reconciliation step that compares paper records with system entries and logs who made each change. Keep an audit trail of threshold decisions and acceptance. Run each path in staging with scripted cases and sample data, have the legal reviewer approve the test results before go-live, and confirm with your verification provider how identity data flows and where it is stored.
How DeployOpen scopes, delivers and supports the initiatives module
DeployOpen plans, installs, customizes, hardens, documents and supports Decidim in infrastructure you control, including the optional initiatives module for resident petitions. Each engagement starts from a written scope that sets out how signatures are collected and verified, and the work is delivered in stages that your team can review.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope names the signature model: online, offline or mixed collection for each initiative type.
- It also records the verification workflow, acceptance thresholds and the identity checks that gate signing.
How we build
- Installation covers the Rails application, PostgreSQL, background jobs, file storage, SMTP and maps.
- Signature collection and verification are configured against the agreed thresholds and tested end to end.
- Authorization rules are set so that only verified participants can sign, and the configuration is documented.
How we hand over
- Handover includes configuration records, runbooks for initiative administrators and the verification steps.
- Your team receives documentation for the offline signature import and checks it is repeatable before go-live.
- Backup and restore steps for the database are documented and tested, with the upgrade approach for later minor versions.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades follow Decidim's one-minor-version-at-a-time guidance, with a database backup taken first.
- Security patches are tracked against Decidim's supported version branches and disclosure timelines.
