What's coming in Central

We wanted to provide more visibility into our roadmap and a rough timeline so you can offer feedback on both the features and our sequencing.

As always, we’ll be able to move faster if we have your help. If you or someone you know can fund this work or help with the development, email yanokwa@getodk.org.

Features we support now

  • Projects to organize users, permissions, and forms
  • User accounts with role-based permissioning
  • Form upload and management
    • With support for form version updates
    • With drafts and testing on initial creation, and on version updates
    • With form multimedia or data attachments
    • Encrypted forms (self-supplied or project managed keys)
    • True deletion of forms
  • Submission upload and management
    • Form filling from our mobile app or a web browser
    • From permissions-managed known users or anonymous public links
    • With submission multimedia or data attachments
    • With an interactive table preview of submission data
    • Support for reviewing, commenting on, and editing submissions after upload
    • Connectable to data analysis and dashboard applications like Excel, Power BI, or R over OData
    • Server-managed datasets for registration/follow-up workflows
  • Integrated checklist-based help system
  • Optional encrypted off-site data backups to Google Drive
  • Clean and modern REST API for integration and extensibility
  • High performance on low-cost hardware or cloud providers
  • ODK Briefcase-compatible data output
  • ODK Briefcase push/pull support

You can find out more about these features at https://docs.getodk.org/central-intro.

Short-term features

  • Delete all or some submissions
  • Documenting running on more cloud providers
    • We’ve provided documentation on Digital Ocean and AWS, but will add GCloud, and Azure.
  • Download form attachments

Long-term features

  • Sync the device to some centrally managed state
    • We’re aiming for a single button push that will sync forms, submissions, and settings.
  • Longitudinal data collection
  • Bulk upload-download user email address and permissions
  • Improved install and upgrades to reduce dependence on command line
  • JSON-based webhook similar to Aggregate's JSON publisher
    • We have an OData feed
    • You can push/pull/export with Briefcase
    • De-prioritized until we have explicit demand for it

Features we’ll likely never add

  • Parsing submissions into database tables
    • Support for arbitrary schemas is a hard problem that introduces a lot of complexity (see Aggregate’s codebase).
  • Visualizing data as pie or bar chart or map
    • We believe this functionality should be pushed to external services through OData
  • Arbitrary database support (e.g., MySQL, SQLServer)
    • We believe PostgreSQL is the best database for our workload.
  • List of previously exported submissions
    • This shouldn’t be necessary since you can regenerate exports quickly
  • Toggling display of submission metadata
    • We will always show you all the relevant data.
  • Export to KML or some other format
    • We do not support KML, but GeoJSON is supported through Briefcase.
    • If there is a wildly popular export that users want, we’ll consider it, but we’d rather not add to our maintenance burden.
  • Publishing to Google Sheets or some other web service
    • The webhook should allow you to connect to other services that can then forward data on to Google Sheets.
    • If there is a wildly popular publisher that users want, we’ll consider it, but we’d rather not add to our maintenance burden.
  • Anonymous retrieval of images, audio, video for visualization
    • We expect downstream visualization tools to be able to securely auth against the server
  • Manually upload submission data
    • We believe this is a rare use-case and Briefcase supports it well.
  • Support of the Briefcase-Aggregate API
    • We believe the extensive RESTful API is better.
  • Running on Google App Engine
    • We value portability over the benefits of a platform as a service. You will be able to use Google Cloud, just not Google App Engine.
  • A non-Docker install
    • We use standard components, so it’s possible to set up Central outside of Docker. We don’t recommend it because we don’t have the resources to support non-Docker installs.

Some considerations to be aware of

If you use App Engine, there’s currently no way to redirect traffic from an appspot domain to another domain. You'll need a plan for changing the server URLs on your devices. If you use your own domain (e.g., with the Aggregate v2.0 or later), that domain can be used with Central.

Our expectation is that most users will keep using Aggregate for ongoing campaigns and will start new campaigns with Central. That is they won’t migrate their data. If migration is needed, Briefcase can migrate blank forms and submissions from Aggregate to Central. Publishers, users, filters, etc will not be moved.

This timeline is not set in stone! We’ll continue to update this post and the timelines as we get new information, so please watch this topic to get updates.

I have a question or comment

Put it below :point_down:


Should these be captured in Server Logs though? So for example I as an admin can know that @chrissyhroberts as a project manager downloaded the data at a certain date-time?

1 Like

@dr_michaelmarks presently this is not planned.

but i know for hipaa / similar reasons it can be a requirement so i'm not opposed to adding it someday.

1 Like

Just a heads up that I've updated the initial post with our progress. The recent changes are:

  1. Upload XLSForm forms has shipped.
  2. Docs for AWS installs are available.
  3. Form versioning and drafts are in progress and will ship in March.
  4. Enketo form preview support will likely ship in July.

Hello, great news.

I think the connection with googlesheet would be very useful to share the data online to multiple users without the need to create individual permissions.

The use of webhook is mentioned as a solution, can you cite those other services that serve as a bridge to bring the data to google sheet? .

Best Regards*

1 Like

One thing that I'd like to explore is a Google App Script that reads from the Central Odata feed and writes the data to a sheet. https://github.com/saiteja09/GoogleSheetsODataReader might be a starting point.

In the next release of Central, it will be possible to directly request a CSV of the root table not in a zip. This will likely make it even easier to get Central data into a Google Sheet. It will still require scripting because of authentication but it will not require any data transformation.

Zapier is an example of a bridge service.


I noticed that You have a "deletion of submissions" as Your long-term goal. Do You have any idea about its time horizon?
Another question, do You plan any paging or even better a cursor-like retrieving of existing submissions in the Aggregate-like style (ie. return all submissions created later than specific submission or specific time)?

Thanks Vranoch

Hi @Jan_Vrana!

We don't currently have a timeline for this feature. However, the upcoming version v1.2 will introduce the ability to review a submission, including the ability to mark a submission as rejected.

As of v1.1, you are able to filter on the submission date using the $filter query parameter. (See the API docs for more information.)


Hi @Matthew_White ,
What does mean the "ability to mark a submission as rejected"? does it actually delete the submission or it just marks it so that it is not returned by the submissions.csv endpoint but it remains in the database?
Thanks Vranoch

The submission will remain in the database, but its "Review State" will be set to "Rejected", and you can filter out such submissions when downloading data. See the release criteria for v1.2 for more details on the planned functionality.

3 posts were split to a new topic: Downloading XLSForm from Central