ArcGIS Enterprise downloads: the blockers you can't see

ArcGIS Enterprise data downloads: how I configure a predictable, fast experience

If I manage a Portal and Enterprise Sites, download behavior will make or break my users’ experience. My teams expect quick files, predictable formats, and a clean path from content to a CSV or shapefile without hoops. The good news: I can shape that experience with the right configuration. The tricky part is knowing where to switch things on, where to cache, and when a link simply will not work the way a browser expects.

Who this is for: Portal administrators, publishers, and Enterprise Sites managers.
Versions referenced in practice: ArcGIS Enterprise 10.9.1, 11.0, 11.1, 11.2.

Prerequisites and service types I check first

I always confirm these before I troubleshoot a missing Download button:

Roles and privileges: I need a role with privileges to create items and publish hosted feature layers, and (for hosted layers) to allow data export. A Publisher or Admin role covers this; a Creator role can work if export privileges are present.
Ownership: I must own the item or be an admin to change export settings.
Sharing: The item’s sharing level governs who sees downloads. A private item will not expose downloads to the public, even if exports are enabled.

I also account for service behavior differences:

Hosted feature layers: Support common export formats and honor filters, view-layer rules, and field visibility. The REST JSON should show supportsExportData: true for export to appear.
Federated ArcGIS Server services: Export may be limited or unavailable depending on capabilities and how the service was published. Some workflows rely on createReplica (Sync) to generate file geodatabases instead of Export Data.
Image services: Export is about imagery formats (PNG, JPEG). Vector formats (shapefile, GeoJSON) do not apply.
View layers: Views inherit the source layer’s export allowance by default. I can explicitly allow or block exports on the view item to control what leaves the system.

If I am unsure, I open the layer’s REST endpoint and check supported operations. If Export Data is not listed for a hosted feature service (or supportsExportData is false), I have likely found a primary reason downloads are missing.

Where I enable downloads (Portal vs Sites)

Downloads in ArcGIS Enterprise flow through two places that work together: the Portal item and Enterprise Sites.

What I do on the Portal item

Open the hosted feature layer’s item page.
Go to Settings.
Under Export, turn on Allow others to export data to different formats. Save.
Confirm service capabilities support my workflow. If I need offline packages, I verify Sync is enabled.
If the site will be public, I share the item with Everyone at the right group or folder structure.

What I do in Enterprise Sites

In Site Manager, I open the Data (or Content Library) area for the site, add the item, and toggle downloads. This controls what visitors see and, if I choose, what gets prebuilt as cached exports.

Common blockers I watch for

Export disabled on the item (toggle off) or the service does not support exporting.
Sync off when an offline or replica workflow is assumed.
Web-tier authentication or token requirements blocking anonymous users.
Federated server items with restricted capabilities or custom definitions that prevent export.
View layers with field-level security removing attributes analysts expect. That can be intentional, but it surprises people.

For large datasets, I do not rely on brute force

I publish view layers filtered to the essential records for public audiences. This reduces file size, protects sensitive fields, and speeds packaging.
I index frequently queried fields to improve packaging performance.
I prebuild exports on a schedule when traffic is heavy and surface those files in Sites for speed.

If I need deeper references, I consult Esri’s ArcGIS Enterprise documentation for: Manage hosted feature layers, Export data from hosted feature layers, Configure organization security (anonymous access), and the ArcGIS REST API (Feature Service properties such as supportsExportData and hasSync).

Formats I choose and why

Picking the right format prevents downstream frustration. My quick takes, with caveats:

Shapefile: Broad compatibility but strict limits - 10-character field names, 2 GB per file, and field count or type constraints. Text can be clipped; nulls may be coerced in some tools. I avoid shapefile for complex domains, long fields, or attachments.
File geodatabase (FGDB): Best fidelity. Domains, subtypes, coded values, attachments, and geometry are preserved. Great for large exports and advanced GIS work. Packaging can take time on very large or complex geometry.
CSV: Fast for tabular data. For spatial layers, XY fields can be included. Coordinates are typically exported in WGS84. Not appropriate for multipart geometries or rich attachments.
Excel: Friendlier than CSV for business users. Workbook row limits apply in downstream tools; I keep an eye on formatting and data types.
GeoJSON: Ideal for web apps and integrations; exports in WGS84. Lightweight and readable, but not designed for extremely large attribute payloads.
KML: Good for visualization (for example, Google tools). Styling is basic versus map services. Geometry-only workflows do fine here.
GeoPackage (GPKG): When enabled, it is a solid single-file option balancing portability and fidelity.
Feature collection: Handy for moving small subsets between apps as compact JSON.
Imagery or raster: Expect PNG or JPEG variants; vector formats do not apply.

How I decide

I need a spreadsheet fast: CSV or Excel.
I need full GIS fidelity: FGDB.
I am integrating with web apps or JavaScript: GeoJSON.
I am exchanging with older systems: Shapefile (with a plan to rename fields).
I need a single portable spatial file and it is supported: GeoPackage.
I want a quick view in Google Earth: KML.

Performance notes I share with stakeholders

Packaging time grows with feature count, geometry complexity (multipart, high vertex counts), and filters.
Cached exports in Sites accelerate repeat downloads, especially for anonymous audiences.
Schema changes (adding or dropping fields, type changes) invalidate caches and trigger regeneration.

Anonymous access and caching strategy

If I expect public use, I align settings across the stack:

Organization setting: If the portal disables anonymous access, no one can download anonymously, even if items are public.
Item sharing: I share items (and any exported files) with Everyone for public downloads.
Sites caching: When I prebuild exports in Sites, the generated files land under the owner’s content (often in an item-exports folder). Those exported items must be shared with Everyone to be discoverable by anonymous users.

How caching behaves in practice

Schema changes regenerate exports.
Attribute-only updates can keep the existing cache unless I force a refresh or schedule one.
If I change filters on a Sites layer card, I rebuild exports to match the new result set.

Protecting sensitive data while staying fast

I expose hosted view layers to the public with only the necessary fields and features. I keep internal layers private.
I limit geometry precision when appropriate for policy (for example, rounding coordinates) to reduce risk.
I apply rate limiting or throttling at the web tier for traffic spikes.
I monitor the item’s Usage tab to spot scraping patterns or broken-link cascades.

I am often told to make it public and fast but keep it secure. I do both by combining view layers (for redaction), appropriate sharing (for governance), and cached exports (for performance).

PDFs that open reliably (and links that actually work)

PDF behavior varies across browsers and devices, so I choose predictable patterns.

For clean open or download behavior

I upload a PDF as a Document item. That item detail page gives users clear Open and Download controls.
In Enterprise Sites, I use a File card to open the document in a new tab, or an Embed card to display it inline.
For consistent controls on mobile (especially iOS), I prefer a custom embed with a viewer like PDF.js hosted on my web tier. This avoids partial renders that some mobile browsers exhibit.
If I want a forced download, I set the HTTP header Content-Disposition: attachment; filename="myfile.pdf". Most browsers will download instead of open.

I do not use file:// links or UNC paths

Modern browsers block file://, UNC paths, and mapped drives from web pages for security. This is a browser limitation documented widely, for example in Linking a UNC or Network drive on an HTML page.
I host PDFs on an internal web server or a secure external host and store HTTPS URLs in a field, such as doc_url. For IIS environments, creating a virtual directory to shared files is a common approach (Microsoft guide to creating a virtual directory). Then I create a dynamic link in the pop-up.

A simple Arcade expression I use for a clean View PDF link

var url = $feature.doc_url;
When(
  IsEmpty(url), "No PDF available",
  '<a href="' + url + '" target="_blank" rel="noopener">View PDF</a>'
)

For more patterns on attribute-based links in pop-ups, Esri’s blog has practical examples: Use attribute-based URL parameters in pop-up links.

CORS and trusted domains

If my document host differs from the portal domain, I add it to the organization’s trusted servers and allowed origins (CORS) to prevent blocked requests.
If the document host sits behind a different authentication system, I aim for a consistent sign-on experience to avoid confusing cross-domain prompts.

Attachments as an alternative

When each feature has one or two documents, I store them as feature attachments and link to the attachment in the pop-up or use an attachments viewer template.
For features with many documents, I use a related table and a gallery-style viewer for better usability.

I keep labels clear and file sizes modest (compressing large PDFs) so field crews and business users know exactly what they are opening and can do it quickly.

The item details page is my control room

I use the item details page to validate configuration and troubleshoot fast:

Tabs that matter

Overview: I check the title, summary, description, thumbnails, owner, last updated date, and sharing level. Users expect prominent Download or Open actions here.
Data: I preview the table, fields, and types to confirm a recommended export format (for example, CSV vs shapefile) will not break on field limits.
Usage: I watch traffic, referrers, and format popularity. If a format gets zero clicks, I simplify the experience by removing it where possible.
Settings: I verify Allow others to export data to different formats for hosted layers, confirm editing and Sync, and enable delete protection when appropriate.
Metadata: I ensure metadata is complete and enabled at the org level if it is hidden.

I also review Related items to find view layers, exported files generated by Sites, and dependent apps that might already expose a Download option I can reuse instead of rebuilding.

Version nuances and planning reminders

Labels and button placement vary slightly across 10.9.1 to 11.x, but the export toggle for hosted feature layers remains on Settings. In Sites, the Downloads toggle may appear as a tab or under a gear icon depending on theme and version.
Before seasonal or fiscal peaks, I prebuild exports during off-hours and verify anonymous access is working from a clean browser session.
I treat export settings as governance, not just toggles. I start with hosted views for public data, keep internal layers separate, and use caching as a usability feature so analysts, crews, and partners get the file they need on the first try.