Dear Survey Solutions team and fellow users,
I am writing from Odisha, India, where Survey Solutions is used for large-scale, continuous official statistics operations — most significantly EARAS (Establishment of an Agency for Reporting Agricultural Statistics), which runs across all 30 districts of the state with a field force running into several thousand primary workers, supervisors and district-level statistical officers.
I would like to propose an enhancement to the user and permission model, and I hope others running comparably large or federated operations will add their experience.
The issue
Survey Solutions currently assumes a three-level operational flow — Interviewer → Supervisor → Headquarters — with a single Administrator sitting above it. This works very well for a centrally managed survey with one operational command centre.
Our governance structure does not work that way. Statistical operations in Odisha are decentralised by design: the District Statistical Office is the accountable unit for its own district’s fieldwork, staffing, data quality and reporting timelines. The state HQ sets standards, owns the questionnaire and consolidates results, but it does not — and realistically cannot — carry out day-to-day operational administration for thirty districts simultaneously.
In practice this means every routine operational action has to be escalated to HQ or the Administrator:
- creating or deactivating supervisor and interviewer accounts as field staff join, transfer or retire (a constant occurrence at this scale)
- resetting forgotten passwords, which at a few thousand users becomes a daily HQ workload
- approving or rejecting interviews, and issuing rejections back to the field
- exporting a district’s own data for local validation, crop-cutting reconciliation and statutory district reporting
None of these are decisions HQ is better placed to make. The district officer knows the staff and the field conditions; HQ becomes a bottleneck that slows the district down while adding no value. During peak seasons this bottleneck directly costs us field days.
Why workspaces do not fully solve it
I am aware of the workspaces feature, and we have considered creating one workspace per district. It solves data separation, but it creates other problems for a single statewide survey:
- the same questionnaire has to be imported and version-managed thirty times, with the constant risk of version drift between districts
- consolidated statewide monitoring and export is no longer a single operation; HQ has to stitch together thirty sets of exports
- assignment allocation and sample management fragment across workspaces
- user administration still ultimately depends on the Administrator; the district officer still cannot independently manage their own team
Workspaces separate data containers. What we need is delegated authority within one survey.
The proposal
A scope-limited administrative role — call it a Regional/District Administrator, or more generally a delegated permission set that the Administrator can define and attach to a defined branch of the hierarchy. Conceptually this is close to the layered, role-based permission model in NADA, where an administrator can grant a collection-level manager real authority over their own collection without exposing anything else in the catalogue.
A district-level administrator in our case should be able to:
- create, edit, deactivate and archive supervisor and interviewer accounts within their own district only
- reset passwords for users below them
- view, approve, reject and comment on interviews originating from their own teams
- assign and reassign assignments among their own supervisors
- export data, paradata and audit logs for their own district only
- see monitoring dashboards and quality indicators scoped to their district
And should explicitly not be able to:
- import, modify or delete questionnaires from Designer
- see, export or act on interviews, users or assignments belonging to any other district
- change survey-wide settings, workspace settings or global configuration
- create or modify other district administrators, or elevate their own permissions
- see statewide aggregates unless explicitly granted
In other words: full operational authority inside one branch of the tree, zero visibility across branches, and no control over survey design.
Suggested implementation direction
Rather than hard-coding a fourth fixed role, the more flexible approach — and the one I suspect would serve the wider user community best — would be for the Administrator to be able to compose permission sets from discrete capabilities (user management, password reset, interview approval, rejection, export, assignment management, monitoring) and bind each set to a node in the user hierarchy. That way an implementation can build whatever number of layers its governance actually requires: state → division → district → block in our case, but two or five levels elsewhere. Audit logging of every delegated action would be essential so that HQ retains full oversight and accountability even where it has devolved the day-to-day authority.
Why this matters beyond Odisha
Any national statistical office, agriculture department or health ministry operating a census-scale or continuous survey through subnational administrative units faces this same mismatch. The three-layer model fits a project team; it does not fit a government structure. Survey Solutions is increasingly being adopted for exactly the latter kind of work, and I think the permission model is the main thing that has not scaled with that shift.
I would be very glad to hear from the development team whether anything along these lines is on the roadmap, and whether there is an interim configuration others have used successfully. I would also welcome hearing from other users running federated implementations — if several of us have the same requirement, that is useful signal.
Thank you for the continued development of an excellent tool.
With regards,
Rashmiranjan Sahu
Statistical Officer, Directorate of Economics and Statistics, Govt. of Odisha, India