Hello everyone,
I’m supporting an environmental nonprofit that is redeveloping its public-facing water quality dashboard. The goals include:
Displaying site-specific water quality data on an interactive map
Allowing the public to download historical data (CSV/spreadsheets)
Keeping certain datasets and reports private for staff-only use
They currently use Power BI and spreadsheets, but are moving more into ArcGIS and want to expand its role in this project.
Has anyone here built a similar workflow in ArcGIS? Specifically, I’d love to learn about:
Best practices for balancing public vs. private data in dashboards
Options for enabling public data downloads while restricting sensitive datasets
Recommendations or lessons learned from nonprofit/public-facing projects
If you have direct experience with this kind of setup, I’d greatly appreciate your insights and would be happy to connect further.
Thank you in advance,
Olusegun
Hi Olusegun,
I’ve worked on several projects where public dashboards were built on ArcGIS Enterprise/ArcGIS Online, with a mix of public-facing content and staff-only datasets, so let me share a few best practices and lessons learned:
Use separate hosted feature layers (or views) for public vs. private data. You can maintain one authoritative dataset, then publish a View Layer that exposes only the fields and features appropriate for public consumption.
For staff use, keep the full layer secured within your ArcGIS Enterprise/ArcGIS Online organization, with role-based permissions.
This avoids duplicating datasets while ensuring data governance.
ArcGIS Hub (or ArcGIS Open Data) is very effective here—it lets you expose downloadable CSV/Excel/GeoJSON files for selected layers. You can configure the Hub site so only the publicly shared layers are downloadable, while sensitive datasets remain private.
For historical archives, you can automate publishing scripts (Python/ArcPy or ArcGIS API for Python) to refresh and expose just the approved fields/rows.
Keep sensitive data in secure feature services with sharing limited to your staff group(s).
If staff need dashboards that combine private + public data, you can create internal-only ArcGIS Dashboards secured with organizational login.
Another option is to use row/field-level filters in view layers, which ensures even if the same base data is used, external users cannot access restricted attributes.
Consistency of URLs: When you update services, keep the same item IDs so public dashboards don’t break. Versioning or Blue-Green deployment approaches can help here.
Performance: Cache basemaps and static layers; for dynamic data, limit the attributes/geometry exposed publicly. This makes dashboards load quickly for community members on different devices.
Transparency: Clearly document the data refresh frequency, last update time, and limitations so the public understands how current the information is.
Engagement: Nonprofits often benefit from embedding feedback mechanisms (ArcGIS Survey123, simple forms) so the community can interact with the dashboard.
Start small: publish a pilot version with 1–2 water quality layers exposed publicly, test the download workflows, and validate with staff that private content is protected. Once the workflow is proven, scale it up across all datasets.
Regards,
Venkat
Hi Olusegun,
Sure. Please find my email address below and let me know if you have any questions.
Regards,
Venkat