Information Technology · Geographic Information Systems
We govern the tools. We do not review every file.
The Red Cross already made this decision for spreadsheets, for business intelligence, and for mapping. One capability never got the same treatment: delivering the custom web applications our own mapping platform requires us to build. This proposes we close that gap the same way we closed the others — by approving a governed lane, once.
01 What We Are Asking For
One governed lane for web application delivery
We are not asking for approval of a project. We are asking for the same kind of decision the organization has already made for every other tool our analysts use: approve the platform, define the rules, and let the work proceed inside them.
A Red Cross-owned code repository organization. All source code owned by the Red Cross, access through Red Cross single sign-on, administered by the Red Cross.
One approved hosting target for static web applications. A single sanctioned place to publish finished applications. Several options qualify and at least one is likely already licensed.
A published standard defining what may be built there. Structural rules that can be checked automatically, not a review queue that depends on a person's availability.
That is the whole request. What follows is why it matters, why it is safe, and why the alternative — deciding one project at a time — is the more expensive and less secure path.
02 A Decision We Have Made Three Times
The pattern is already established here
Nobody at the Red Cross security-reviews an individual spreadsheet. Nobody reviews each Power BI report before it is shared, or each ArcGIS Online dashboard before it is published. That is not an oversight. It is a deliberate and correct design.
In each case the organization evaluated a platform once, established how identity, access, and data boundaries work inside it, and then let people build. Governance lives at the platform layer. The individual artifact does not need its own approval, because the platform already constrains what any artifact can do.
| Capability | Governed at | Per-artifact review? |
|---|---|---|
| Spreadsheets and analysis | Microsoft 365 tenant, identity, data policy | No |
| Business intelligence and reporting | Power BI workspace, licensing, data gateways | No |
| Maps, dashboards, and configured apps | ArcGIS Online organization, named users, sharing model | No |
| Custom web applications | Nothing. No lane exists. | Every time, individually |
The last row is the entire problem. Because no lane exists, every piece of work becomes its own negotiation, and the answer depends on who is asked and when. That is not a security posture. It is the absence of one.
03 The Gap Esri Leaves Open
Our mapping platform requires customer-supplied hosting. By design.
ArcGIS Online covers a great deal. Configurable templates, dashboards, and the online version of Experience Builder handle most routine needs well, and we should keep using them for exactly that work.
Beyond that tier, Esri provides a software development kit for building custom applications — and then states plainly that it will not host what you build with it:
ArcGIS Online does not support hosting custom web apps. You will need to host your own web apps on your own web server, which can then be referenced as items in your ArcGIS Online organization. Esri Community — hosting an HTML or web application in ArcGIS Online
The same limit applies to the developer edition of Experience Builder, the supported route for extending Esri's own application builder:
There is no way to host custom apps created with Developer Edition in ArcGIS Online. Esri Community — publishing Experience Builder Developer Edition to ArcGIS Online
The point
This is not a workaround, a preference, or an individual working around policy. It is the documented architecture of the platform the Red Cross already purchased. Esri sells the development kit, documents it, supports it — and requires the customer to supply the web server. Any organization using the full capability of ArcGIS faces this same requirement. We simply have not answered it yet.
One clarification worth confirming early: if the Red Cross operates a self-hosted ArcGIS Enterprise portal anywhere in the organization, its web server may already satisfy this need, and the request becomes considerably smaller. Our understanding is that we are an ArcGIS Online organization, which has no such server. That question is worth five minutes before anything else is decided.
04 A Smaller Risk Than One Already Approved
These applications hold no data
The instinct is that adding a hosting service adds exposure. Here the opposite is true, and the reason is architectural rather than procedural.
A finished application of this kind is a set of static files — markup, styling, and scripts. It has no database and no server-side logic. When a Red Cross staff member opens it, their browser signs in against our own ArcGIS organization and requests data directly from Esri. The data path never touches the host. The host stores and serves files. It never sees a record.
Two consequences follow, and both matter more than any assurance a person could give:
- The permission model does not change. Access is decided in ArcGIS, per named user, exactly as it is today. An application cannot show anyone anything they could not already open themselves in ArcGIS Online.
- The risk is lower than what we already accepted. ArcGIS Online is a third-party hosted service that holds real Red Cross operational data. We accepted that years ago, under contract, and it works. A static file host holds none of it. We are asking to approve a less sensitive category of service than the one already in production.
05 Why Project-by-Project Review Fails
The bottleneck is a person, and that is the actual risk
Requests for this kind of tool now arrive from across the organization. Reviewing each one individually does not scale, for the same reason we never reviewed every workbook: there are too many, they arrive continuously, and the reviewer becomes the constraint on the entire organization's ability to build.
Worse, a per-project gate concentrates risk on one person's judgment and availability. If that person is unavailable, work either stops or routes around the gate. Neither outcome is what anyone wants.
The structural argument
Per-application review here is not merely expensive. It is redundant. Because these applications store no data and inherit ArcGIS permissions unchanged, the blast radius of any one of them is bounded before anyone looks at it. The architecture provides the control that a reviewer would otherwise be asked to provide by inspection. That is precisely why no one reviews individual Power BI reports — and the same logic applies here, for the same reason.
Controls belong where they can be enforced automatically and consistently: in the platform defaults, in the published standard, and in automated scanning. Not in a queue.
06 What This Makes Possible
Capability the configured tools cannot reach
Esri's configurable products are strong and should remain the default for routine needs. The development kit exists because some problems sit past what configuration can express. These are the categories where the difference is real:
Fusion
Many sources, one view
Combining independent authoritative sources in a single picture while keeping each measurement attached to its own source and timestamp, rather than silently averaging them together.
Dimension
Three-dimensional and time-based analysis
Terrain, structure, elevation, and change over time, presented so the pattern is legible to a decision maker rather than only to an analyst.
Purpose
Interfaces built for one decision
A screen shaped around the actual question being asked, instead of a generic widget arrangement the reader must first learn to operate.
Field use
Built for pressure
Behavior tuned for how responders actually work — fast, legible under stress, dependable on the devices and connections they really have.
These capabilities are directly applicable to disaster response, facility and service planning, volunteer and resource distribution, and public and donor communication. The constraint on using them has never been skill or need. It has been the absence of an approved place to publish the result.
07 The Governed Lane
Rules that a machine can check
A lane is only safe if its boundaries are structural. These rules are absolute, and each can be verified automatically rather than by inspection:
| Rule | Why it holds |
|---|---|
| No data stored at the host | Applications are static files. There is no database to breach and no records to lose. |
| No credentials in application code | Automated secret scanning blocks it at commit time, before code is ever published. |
| All access through Red Cross single sign-on | Identity and permissions stay in systems we already administer. |
| No personal or client information | Sensitive records stay in their systems of record. Applications reference, never copy. |
| No anonymous path that can write | Anything published openly is read-only. Write access always authenticates. |
What enforces them
- A template repository so every new application starts compliant instead of being corrected afterward.
- Platform defaults — protected main branches, required review before merge, dependency and secret scanning switched on organization-wide.
- A documented intake path so requests from around the organization route into the lane and are answered consistently, rather than depending on who happens to be asked.
This is the part that turns a personal practice into an institutional capability. It also gives the Red Cross something it does not have today: a defensible answer when a request should be declined.
08 Ownership and Continuity
The Red Cross owns the code, from day one
To be explicit, because it is the most important commitment in this proposal: the Red Cross controls the repository, the code, and the long-term ownership. Not an individual, not a contractor, not a personal account. Organization-owned from the first commit, with access administered through Red Cross identity.
These tools are built with maintenance in mind — clear structure, plain navigation, documented so another person can pick up the pieces. If the person who built a tool leaves tomorrow, the organization keeps the tool, the source code, and the ability to change it.
Worth stating directly
Continuity is not a side benefit of this proposal. It is one of the strongest arguments for it. Any capability that lives outside an organization-owned account depends on an individual. Approving this lane is how the Red Cross takes permanent ownership of work it depends on — which is exactly what a good steward should want.
09 The Decision
What we need, and from whom
Confirm whether a self-hosted ArcGIS Enterprise portal already exists. If it does, its web server may cover most of this and the request shrinks considerably. A short conversation with the GIS platform owner.
Approve a Red Cross-owned code repository organization. Owner: Information Technology, with a named administrator. Access through existing single sign-on.
Name one approved static hosting target. If the Red Cross runs on Microsoft infrastructure, Azure Static Web Apps is the shortest path and may already be covered by current licensing. Enterprise code-hosting pages and comparable managed services are equivalent. We are asking for a decision, not a specific vendor.
Publish the standard and the intake path. Jointly drafted by Information Technology and Geographic Information Systems, then published so the rules are the same for everyone.
None of these require new spending in the likely case, and none require anyone to review an individual application. They require one decision, made once, of the same kind the organization has already made successfully three times.
10 Questions We Expect
Answered plainly
Why not just use ArcGIS Online for everything?
We should, wherever it fits — and it fits most of the time. This proposal only concerns the work Esri's own platform explicitly cannot host, which is the work built with the development kit Esri sells for exactly that purpose.
Does this put Red Cross data on another vendor's servers?
No. The data path runs from the staff member's browser to our own ArcGIS organization. The host serves application files and never receives a record. Notably, our operational data already sits with a third party — Esri — under contract, and has for years.
What stops someone from publishing something they should not?
The same thing that stops it in ArcGIS Online today: their own permissions. An application cannot expose data the person using it could not already access directly. Beyond that, secret scanning, protected branches, and required review before merge are switched on by default across the organization.
Who maintains this after the person who built it moves on?
The Red Cross, because the Red Cross owns it. That is the entire point of asking for an organization-owned repository rather than continuing without one. See section 08.
What does it cost?
Likely nothing new. Enterprise code hosting and static web hosting are commonly included in agreements an organization of this size already holds. Confirming that is part of step 3.
Why now?
Because demand is arriving from across the organization and there is no lane to route it into. Every week without one produces either work that stalls or decisions made informally. A published standard is better than both.
Prepared for discussion. This document proposes a governance decision and does not describe an approved Red Cross position. It is not an official Red Cross publication.
Sources: Esri Community on hosting custom applications · Esri Community on Experience Builder Developer Edition · Esri Developer documentation on Experience Builder deployment