Allow add-ins to provide custom dialogs (or custom parameter controls) for geoprocessing tools

JeffJenness

Summary of the problem

The geoprocessing framework is one of ArcGIS Pro's greatest strengths, and third-party developers are rightly steered toward it: a tool built as a script tool or Python toolbox gets geoprocessing history, environment settings, progress and message reporting, batch mode, ModelBuilder composability, and arcpy scripting — an ecosystem no custom dialog could ever rebuild.

But that ecosystem comes bundled with exactly one user interface: the auto-generated geoprocessing pane. There is no supported way for a third-party tool to present any other UI while remaining a real geoprocessing tool. For simple tools the generated pane is fine. For interactive, feedback-rich workflows it is severely limiting, and developers face an unnecessary either/or:

• Stay a GP tool and accept the generated pane's limits (no custom widgets, no live previews, limited layout control, and a long tail of validation-behavior quirks), or
• Build a custom dockpane/window with exactly the right UI — and lose geoprocessing history, environments, ModelBuilder, batch, and scripting entirely.

Esri's own flagship interactive workflows demonstrate the problem: the Suitability Modeler, the image Classification Wizard, and Georeferencing are all custom panes, not generated geoprocessing dialogs. When rich interaction matters, Esri routes around the GP pane. Third-party developers have no supported way to do the same without abandoning the geoprocessing framework.

Requested enhancement

Decouple the tool UI from the tool. Two tiers, either of which would be a major step:

Tier 1 — custom tool dialogs (the full request). Let an add-in register a WPF dialog/pane as the Pro UI for a specific geoprocessing tool (script tool, .pyt, or .atbx). The tool remains a first-class GP tool in every other respect:

• The custom dialog gathers and validates parameters, then hands a standard parameter array to the normal GP execution pipeline — so the run is recorded in geoprocessing history, honors environment settings, reports progress/messages, and stamps metadata exactly as today.
• Contexts that cannot host the custom dialog — ModelBuilder, batch mode, scheduled runs, server publishing, arcpy — automatically fall back to the auto-generated pane and existing parameter objects. Nothing breaks.
• If no custom dialog is registered, behavior is exactly today's (fully backward compatible).

Tier 2 — custom parameter controls (a smaller but still transformative request). Let a developer register a custom WPF control for an individual parameter (or a custom parameter datatype), hosted inside the generated pane. Even this would eliminate most of the pain: a value table could become a real grid with live feedback; a remap parameter could show a histogram of the input raster; a threshold could show which cells it selects.

Why it matters

Custom Python toolboxes are a first-class extensibility path for ArcGIS Pro, and organizations and third parties build serious, commercial-grade analysis suites on them. The quality of what the user sees is capped not by the developer's effort but by the generated pane. Developers who care about user experience are pushed to abandon the geoprocessing framework — losing provenance, reproducibility, and scriptability, the very things that make Pro tools trustworthy. A supported UI extensibility point would end that trade-off, raise the quality bar of the whole third-party ecosystem, and cost nothing in backward compatibility.

JeffJenness

Concrete limitations met while building one real toolbox — all encountered (and independently reproducible) while porting a large wildlife-analysis toolset to a Python toolbox in ArcGIS Pro 3.7. Each is livable alone; together they show why a supported custom-UI path is needed. Items marked ◆ are also candidates for individual bug reports via My Esri support.

1. ◆ Value-table cell marshaling is inconsistent and undocumented. During dialog validation, a GPValueTable cell holding a map layer or table arrives as the bare display-name text when dragged in, but as a wrapper object (MappingLayerObject / MappingTableObject) whose str() is only a repr (<MappingTableObject object at 0x…>) when picked from the cell's dropdown. Validation code must defensively handle both; naive str() use produces false "does not exist" errors.
2. ◆ No supported project access during validation. arcpy.mp.ArcGISProject("CURRENT") is unreliable/unsupported in updateParameters, so a tool cannot resolve a layer name to its data source to drive smart defaults (e.g., suggesting a companion table that sits beside the input raster in a geodatabase).
3. No opt-out of framework output auto-naming. When the first input changes, Pro fills an empty required output with <first input>_<tool name>. For multi-input tools the first input is often not what the output is about (e.g., one habitat factor out of six), so the suggestion is reliably wrong — and the tool cannot suppress it.
4. No way to set the Browse dialog's starting location per parameter, even when the tool knows exactly where the relevant files live.
5. "Suggest once, let the user clear it" requires an undocumented idiom. .altered does not distinguish a user-cleared value, so usable auto-defaults hinge on the undocumented hasBeenValidated behavior.
6. ◆ A disabled output parameter that still holds a value gets its dataset deleted on Run (overwrite-output pre-delete runs before execute()), even though the parameter is disabled — a data-loss trap for mode-toggle dialogs.
7. No show/hide for parameters, and limited layout control. Category groups always render below all uncategorized parameters, and categories default to collapsed; a parameter cannot be hidden when a mode makes it irrelevant.
8. Empty value-table rows added with "Add another" are pruned whenever the pane refreshes or loses focus, so a user cannot click Browse in a freshly added row — and dragging a layer onto the control does not append a row either. The cell dropdowns are the only reliable way to add a row.
9. Raster inputs can surface as CIMPATH=…/….json URIs in .valueAsText that arcpy.Describe/CopyRaster reject, requiring resolution through the value object instead.
10. No custom widgets of any kind. No histogram or preview of an input raster, no live chart, no color swatches, no rich text. In our suite, an interactive remap-table builder had to be written as a fully custom add-in window — losing geoprocessing history for that step — because the pane simply cannot host it.
11. The multivalue value-list control always offers "Select All," even when selecting everything is semantically wrong — a geographic-transformation list where exactly one entry per datum pair is meaningful, say. No toolbox property suppresses or renames it.
12. ◆ Geometry filters cannot be applied to mixed raster/feature parameters. Parameter.filter.list = ["Polygon"] works on a feature-only composite (["GPFeatureLayer", "DEFeatureClass"]), but raises NameError: The attribute 'list' is not supported on this instance of Filter the moment raster types join the composite (["GPFeatureLayer", "GPRasterLayer", "DEFeatureClass", "DERasterDataset"] — the natural datatype for a tool that combines polygon layers AND rasters in one multivalue list). Consequence: a polyline or point layer cannot be refused at drag-in or browse time; the only available protection is an error posted from updateMessages, which does block Run but only after the wrong layer already sits in the list — and which the developer must remember to re-post on every validation cycle, since messages are cleared each pass.

Why existing workarounds don't substitute: a custom window that calls processing code directly orphans the run from history, environments, and scripting; a custom window that wraps the GP tool via ExecuteToolAsync preserves those but forces the developer to build and maintain two UIs per tool, and ModelBuilder users still see only the generated pane. Both paths exist precisely because the supported one is missing.

I'm happy to file the ◆ items individually via My Esri support and cite this idea as the systemic fix, if that's useful — let me know.