The desktop powerhouse — projects and settings, geoprocessing, the symbology and labeling engine, print layouts and map series, and ModelBuilder.
One of eight volumes. Approximately 22625 words. Chapters cross-reference the whole set by number.
In this volume:
ArcGIS Pro is the desktop half of the ArcGIS platform — the heavyweight application you install on a Windows machine when browser tools stop being enough. Where Map Viewer (see Chapter 6) runs in a tab and saves everything to your organization's portal (the web hub where shared GIS content lives), Pro runs on your own hardware, works with files on your own disks, and wraps everything you do inside a container called a project. Understanding that container — what it holds, what it merely points to, and how it can break — is the single most useful thing you can learn before touching any of Pro's analysis or cartography tools. This chapter is the orientation: projects, the ribbon, the two panes you will live in, the views you work inside, and the handful of settings that quietly shape everything else. The chapters that follow in this volume assume all of it.
When you start Pro, it asks you to create or open a project. A
project is saved as a single file with the extension .aprx
— the ArcGIS Pro project file. It is the successor to the old ArcMap
.mxd map document, but it is more ambitious: one project
can hold many maps, many layouts, 3D scenes, tables, charts, connections
to folders and databases, a history of every analysis you have run, and
more.
Here is the concept that saves people the most grief: the .aprx file stores instructions, not data. When you add a shapefile or a geodatabase layer to a map (two common storage formats for spatial data — Chapter 1 covers both), the project records where that data lives on disk plus everything about how to draw it — symbology, labels, pop-up configuration, filters. The actual points, lines, polygons, and rasters stay wherever they were. The .aprx is a recipe book, not a pantry.
This design keeps project files small and lets many projects reference the same data. It also means a project is only as healthy as the file paths it remembers.
Watch out: Copying just the
.aprxfile to a USB stick or emailing it to a colleague does not move your data. On the other machine, every layer will show a red exclamation mark meaning "I can't find my source." If you need to hand a whole project to someone, use a project package — covered at the end of this chapter.
Every project has a home folder — the folder on disk where
the .aprx lives. By default, when you create a project named
HarborStudy, Pro creates a folder called
HarborStudy, puts HarborStudy.aprx inside it,
and treats that folder as home. The home folder is the default location
for anything you import or export, and it appears automatically at the
top of your folder connections in the Catalog pane. Treat it as the
project's territory: keep the data that belongs to this project inside
it, and moving or backing up the project becomes a matter of moving one
folder.
Alongside the .aprx, Pro creates a file geodatabase — a
folder ending in .gdb that acts as a spatial database
(Chapter 1 explains the geodatabase data model in depth). This is the
project's default geodatabase: whenever you run an analysis
tool and don't say where the output should go, the result lands here.
Run a buffer, a clip, a spatial join — the new layers all accumulate in
the default geodatabase unless you deliberately point them
elsewhere.
That convenience has a dark side. After a week of exploratory
analysis, the default geodatabase becomes a junk drawer of
Buffer_1, Buffer_2,
Clip_Output_Final_v3. Nothing is wrong with that during
exploration, but plan to clean it out or to redirect finished outputs
somewhere deliberate. You can see and change which geodatabase is the
default in the project's Catalog pane (it wears a small home icon) —
right-click any other geodatabase and look for the option to make it the
default.
The project also gets a default toolbox — a container
(.atbx in recent versions) for any custom tools or models
you build. When you create a model in ModelBuilder (Chapter 25) or add a
script tool (Chapter 31), it is stored here unless you choose another
toolbox. For most beginners the default toolbox sits empty for a long
time, and that is fine.
When Pro starts, the opening screen offers several project templates. They differ only in what the new project opens with:
| Template | What you get on open |
|---|---|
| Map | One 2D map with a basemap — the usual choice |
| Global Scene | One 3D scene of the whole globe |
| Local Scene | One 3D scene clipped to a local area |
| Catalog | No map at all — just a data-management view |
| Start without a template | An untitled session that is not saved to disk unless you choose to save it |
"Start without a template" deserves a note: it lets you open Pro, poke at some data, and quit without leaving a project folder behind. If you decide the session was worth keeping, you can save it as a project at that point. For anything you expect to return to, create a named project from the start.
How many projects should you have? A reasonable rule: one project per real-world effort. A project can hold many maps, so you do not need a project per map — but you also should not cram every piece of work you do into one giant "everything" project, because projects with dozens of maps and hundreds of connections open slowly and become impossible to hand off.
Across the top of Pro runs the ribbon — the same horizontal band of tabs and buttons you know from Microsoft Office. Pro's ribbon has one behavior that confuses everyone at first and then becomes second nature: it changes based on what you have selected.
A core set of tabs is always there. Their names have shifted slightly across versions, but the roles are stable:
Project > Options dialog.Now the moving part. Click a feature layer in the Contents pane, and a new group of tabs appears — typically named something like Feature Layer, with sub-tabs for appearance (symbology, transparency), labeling, and data. Click a raster layer instead, and the group changes to raster-specific tabs. Open a layout, and layout tabs appear. Select a table frame inside that layout, and table-frame tabs appear.
The rule to internalize: if a button you remember has vanished, you probably don't have the right thing selected. The symbology controls are not gone — Pro is just not showing them because no layer is active. Click the layer's name in the Contents pane (the name itself, not its checkbox) and the tabs come back.
Tip: When you cannot find a command at all, use the Command Search box at the top of the window (the search field on the title bar). Type what you want to do — "swipe", "georeference", "import symbology" — and Pro finds the command and can run it directly, even highlighting where it lives on the ribbon. This one habit replaces most ribbon-hunting frustration.
Above the ribbon by default (it can be moved below it) sits a tiny strip of icons — Save, Undo, Redo. You can right-click almost any ribbon button and add it to this Quick Access Toolbar. If you use a command constantly (Save Edits is a popular candidate), pin it there and stop caring which tab it lives on.
The Contents pane is the tall panel, usually docked on the left, that
lists everything in the currently active view. For a map, that means
layers; for a layout, it means layout elements like map frames and
legends. If you have used Map Viewer's Layers panel, this is the same
idea with far more depth. If you ever lose it, reopen it from
View > Contents.
At the top of the Contents pane is a row of small icons that change how the contents are listed. The default lists layers by drawing order — top of the list draws on top of the map. The other modes re-sort the same layers by different questions:
Beginners live in drawing order and forget the rest exist. Remember at least "by selection" and "by editing": when Pro refuses to select or edit something and you cannot see why, one of these modes usually holds the answer.
Three distinct interactions on every layer, and they do different things:
Layers can be nested into group layers (right-click selected layers and group them), which lets you toggle and organize related layers as a unit — invaluable once a map passes a dozen layers.
If Contents answers "what is in this map," the Catalog pane answers
"what can this project touch." Open it from
View > Catalog Pane. It is a tree of everything
connected to the project, organized under a few top-level tabs.
The Project tab lists containers, each holding one kind of resource:
There are more (layouts have their own container, as do reports and connections to servers) but the pattern is uniform: right-click a container to add or create things of that kind, right-click an item to act on it.
The Portal tab shows content from the portal you are signed in to — your own hosted items, your groups, your organization, and the Living Atlas (Chapter 5). This is how cloud content flows into desktop maps: find a hosted feature layer here and drag it straight into a map.
The Favorites tab holds connections you have promoted to appear in every project — more on this shortly.
Pro also offers a Catalog view
(View > Catalog View), which opens the same tree as a
full tab in the center of the screen, with a details panel showing
previews and metadata. The pane is for quick access while you work on a
map; the view is for sessions where data management is the work
— browsing, documenting, previewing, batch-renaming. Same content, two
lenses.
Watch out: Deleting something in the Catalog pane deletes it from disk, immediately, with no Recycle Bin safety net for geodatabase contents. Deleting a layer from a map just removes the reference; deleting a feature class (a dataset stored inside a geodatabase) from Catalog destroys the data. Read the confirmation dialog before clicking through it.
One more quirk worth knowing early: the Catalog tree does not always notice changes made outside Pro. If you copied files into a folder using Windows Explorer and they are not showing up, right-click the folder and choose Refresh.
Everything you open in Pro — a map, a 3D scene, an attribute table, a layout, a chart, the Catalog view — opens as a view: a tab in the central area of the window. You can have many views open at once, switch between them like browser tabs, and drag a tab to float it or dock it beside another so two views share the screen.
The distinction between panes and views keeps the interface legible: views hold content you look at (maps, tables, layouts); panes hold controls and lists (Contents, Catalog, Symbology, Geoprocessing). Panes dock around the edges; views fill the middle.
A map is a 2D view. A scene is a 3D view, and it comes in two flavors: global scenes drape your data over the whole curved earth (right for country-to-planet scale work), while local scenes use a flat projected surface clipped to an area of interest (right for cities, campuses, and underground or indoor work where the earth's curvature is noise). You can convert a map to a scene and back from the View tab, though symbology does not always translate perfectly.
One project can hold many maps and scenes. The Contents pane always describes whichever view is currently active — a constant source of momentary confusion when you have five tabs open and the pane suddenly "loses" your layers because you clicked into a different map.
Opening a layer's attribute table (right-click the layer, then Attribute Table) creates a table view, which by default docks along the bottom so you can see the map and the rows together. Selecting a row highlights the feature on the map and vice versa. Everything about fields, calculations, and table tools is covered in Chapters 9 and 12.
A layout is a page — a composition of map frames, legends,
scale bars, and text destined for print or PDF. Layouts are views too,
opened from Insert > New Layout. They get a full
treatment in Chapter 24; for now just know that a layout contains one or
more map frames, each pointing at one of the project's maps,
and that editing a layout is a different mode from editing a map.
When comparing two maps of the same area — before-and-after imagery, two scenarios, a 2D map beside a 3D scene — you can link views so they pan and zoom together. The option lives on the View tab (Link Views). It sounds like a novelty; it becomes indispensable the first time you QA two versions of a dataset side by side.
Two features exist to stop you from rebuilding the same setup in every new project.
Favorites. Any folder connection, database connection, server connection, or toolbox can be added to Favorites (right-click it in Catalog and add it, or drag it onto the Favorites tab). Favorites appear in every project. Better still, each favorite can be marked to be added to new projects automatically, so your team's shared data folder or your organization's enterprise geodatabase connection is simply there every time, no setup. If you find yourself making the same folder connection three projects in a row, that is the signal.
Project templates. A project template (saved as an
.aptx file) is a frozen starting point: maps already added,
layers already styled, connections already made, layouts already
designed. Create one by building a project the way you want new projects
to begin, then sharing it as a project template from the Share tab.
Teams use templates to enforce consistency — every new inspection
project starts with the same basemap, the same symbology, the same
layout shell. If you are a solo user, a personal template with your
favorite basemap and coordinate system is a small luxury that pays
daily.
Pro has a large settings dialog at Project > Options,
split into two groups: settings for the current project and
settings for the application (every project on this machine).
Most defaults are sensible. A handful are worth changing
deliberately.
Under the general application settings you can choose where new projects are created and whether each gets its own folder. Point this at a real working location (not a cloud-synced desktop — more on that below) and every future project starts in the right place.
By default, a new map takes its coordinate system from the first layer of your own data added to it — the basemap does not count — meaning your map's projection is decided by whichever dataset you happened to drag in first. In the Map and Scene section of Options you can instead set a specific default coordinate system for all new maps. If your work lives in one region, setting your regional projected coordinate system here is one of the highest-value configuration changes available.
Tip: If terms like "projected coordinate system" are still fuzzy, read Chapter 3 (Coordinate Systems and Projections) before setting this option. The short version: a deliberate default beats an accidental one, because the map's coordinate system silently controls how measurements behave and how every layer is redrawn to fit.
The Geoprocessing section of Options contains a famous checkbox: allow tools to overwrite existing outputs. With it off (the cautious default), rerunning a tool with the same output name fails with an error; with it on, the rerun silently replaces the earlier result. Analysts who iterate constantly usually turn it on and accept the risk knowingly. The same page controls whether your geoprocessing history is logged — leave logging on; the history of what you ran, with what parameters, is your analysis audit trail and lives in the project.
Distinct from Options are geoprocessing environments —
settings like output coordinate system, processing extent, and cell size
that tools inherit. They are set at
Analysis > Environments for the project, or per-tool
inside each tool's Environments tab. The one to know about early is the
parallel processing factor, which tells tools that
support it how many of your CPU's cores to use. Some tools honor it and
speed up dramatically on multi-core machines; others ignore it entirely.
Chapter 22 covers environments properly; for now, just know that "why is
this tool only using one core?" has a settings answer.
The Display section trades visual quality against speed — antialiasing settings, rendering engine, hardware acceleration. If Pro feels sluggish or you see graphical glitches, this page (and updating your graphics driver) is the first stop. Laptops with two graphics chips sometimes run Pro on the weak one; forcing the dedicated GPU in your system's graphics settings is a classic fix.
One behavioral setting deserves a flag even though editing gets its
own chapter: in Pro, saving the project and saving your edits
are separate acts. Save on the Quick Access
Toolbar saves the .aprx — the maps, layouts, and settings. Feature edits
are saved (or discarded) from the Edit tab. The Editing page of Options
can change how much of this is automatic. Chapter 13 covers the full
workflow; until then, when you have been digitizing for an hour, make
sure you have saved edits, not just the project.
A fresh project can see almost nothing. You grant it reach by making
connections, and all of them start from either the Insert tab
(Insert > Connections) or a right-click in the Catalog
pane.
A folder connection makes a disk location visible in Catalog —
Insert > Connections > Folder > Add Folder Connection,
then browse to the folder. Connect the folder you actually work in, not
C:\, so the tree stays navigable. Network shares work the
same way, with the usual caveat that a project referencing data on a
share needs that share reachable to draw its layers.
Under database connections you will meet two very different animals
wearing the same icon family. A file geodatabase
(.gdb) is just a folder on disk — you can create one
anywhere, no server required, and it is the right default for personal
and project data. An enterprise geodatabase connection
(saved as an .sde file) is a doorway into a real database
server — PostgreSQL, SQL Server, Oracle — managed by a database
administrator, holding data that many people edit at once. Creating one
requires server details and credentials that someone in your
organization provides. If you are wondering whether you need one, you
almost certainly do not yet; Chapter 35 (ArcGIS Enterprise) explains the
world where you would.
Pro is signed in to a portal — either ArcGIS Online or an
ArcGIS Enterprise portal — and this connection is unusually important
because it does double duty: it is where your shared content lives,
and it is typically how Pro checks its license. Manage portal
connections from Project > Portals on the backstage. You
can list several portals, but exactly one is active at
a time, and the active portal is what the Catalog pane's Portal tab
shows, where Share operations publish to, and what basemap and geocoding
services you draw on.
Watch out: If Pro refuses to start or drops to a licensing error, the portal sign-in is the first suspect — an expired password or an unreachable portal can lock you out of the whole application. Most organizations allow an offline mode for travel; set it up before the flight, not in the departure lounge.
You can also connect directly to GIS servers, cloud storage, and
similar endpoints (all under Insert > Connections).
These matter mostly in Enterprise contexts and are noted here only so
the menu doesn't intimidate you.
Projects rot in predictable ways. A little discipline prevents most of it.
The red exclamation mark next to a layer means the project looked for the layer's data at its remembered path and found nothing — the data moved, the drive letter changed, the network share is offline. Clicking the exclamation mark opens a browse dialog to point the layer at the data's new location, and Pro is helpfully aggressive about repair: fix one layer, and it automatically fixes any other broken layers whose data moved to the same place.
Prevention beats repair. Keep a project's data inside its home folder where possible, and move the folder, never the loose .aprx. Be especially wary of building projects on data in cloud-synced folders (OneDrive, Dropbox and the like) — sync tools and geodatabases interact badly, because a geodatabase is many files that must change together and a sync tool can catch it mid-write.
When a project must travel — to a colleague, a client, or your future self on a new machine — Pro can bundle the recipe and the pantry into a single package file. All of them live under the Share tab:
| Package | Extension | What it bundles |
|---|---|---|
| Project package | .ppkx |
The whole project: maps, layouts, connections, and copies of the data |
| Map package | .mpkx |
One map and copies of its data |
| Layer package | .lpkx |
One layer, its symbology, and its data |
| Project template | .aptx |
A project starting point, for creating new projects |
Packaging consolidates — it copies referenced data into the package so the recipient needs nothing else. That is the point, and also the caveat: a project referencing large rasters becomes a very large package. Packages can be saved as files or uploaded to your portal for the recipient to download. When someone sends you a package, opening it unpacks the contents to your machine and opens a working project.
Tip: A project package is also a first-rate archive format. When a project ends, package it. Years later, the package still contains everything, while the original folder-of-loose-references has usually decayed.
A short maintenance list, worth running monthly on any project you care about:
The .aprx itself is small — back it up freely and often, ideally the entire home folder as a unit. Pro also keeps periodic recovery information while you work, so after a crash it will usually offer to restore a recent state of the project; the interval is adjustable in the application options. Recovery restores the project file, not necessarily unsaved feature edits — one more reason the save-edits habit from Chapter 13 matters.
That is the tour. You now know where everything lives: the project as the container of recipes, the home folder and default geodatabase as its territory, the ribbon as a context-sensitive command surface, Contents and Catalog as the two constant companions, views as the tabs where the work happens, and packages as the way projects travel. Chapter 22 builds directly on this foundation and takes you into the geoprocessing framework — the reason most people open Pro in the first place.
Every analysis you will ever run in ArcGIS Pro — every buffer, every clip, every table join, every raster calculation — passes through one shared piece of machinery called the geoprocessing framework. Understand that framework once and you understand hundreds of tools at the same time, because they all follow the same contract: you hand a tool some inputs and some settings, it does one well-defined job, and it hands back an output without touching your original data. This chapter is about the framework itself — how to find tools, how to read their dialogs, and, most importantly, the invisible settings that can quietly change your results without any error message. The individual analysis tools get their own treatment in Volume D (Chapters 16 through 20); here you are learning the machine they all run inside.
If you have run even one tool before, you have already used the framework. What you probably have not done is looked underneath it, and underneath is where the surprises live.
"Geoprocessing" is Esri's word for any operation that takes geographic data in and produces something out — a new dataset, a modified table, a report, a chart. The operations themselves are packaged as tools, and tools are organized into toolboxes, which are grouped by theme: analysis tools, data management tools, conversion tools, and so on. ArcGIS Pro ships with a very large number of them, from tiny utilities that rename a field to heavyweight solvers that route trucks across a continent.
Every tool honors the same basic contract, and internalizing it will save you real grief:
One more piece of vocabulary: tools run against layers when you pick something from your map, and against datasets when you browse to a file on disk. The distinction matters, because a layer carries baggage — selections, definition queries, join state — that the raw dataset does not. Hold that thought; it becomes important two sections from now.
The front door is the ribbon: Analysis > Tools opens
the Geoprocessing pane, which is where you will spend most of your
analytical life. The pane has a search box at the top and a couple of
ways to browse underneath it.
Searching is almost always faster than browsing. The search matches tool names, keywords, and descriptions, so you do not need to know what Esri called something — search for what you want to do. Typing "merge" finds the tools that combine datasets; typing "distance" surfaces buffering, near-analysis, and distance rasters; typing "table to excel" finds exactly what it sounds like. Results are grouped and ranked, and hovering over a result shows a summary so you can tell similar-sounding tools apart before opening anything.
Tip: When two tools have confusingly similar names — and they will; the classic examples are pairs like Clip versus Intersect, or Merge versus Append — open the tool and follow its help link. The help page for every tool includes an illustration of what it does to the geometry. Thirty seconds with the picture beats an hour of running the wrong tool convincingly.
Browsing has its place too. The Toolboxes tab in the Geoprocessing pane lists every toolbox in an expandable tree, which is the best way to discover what exists in a domain you are new to — scrolling through the Spatial Statistics toolbox is a genuinely good way to learn what spatial statistics can even do. The Favorites tab collects the tools you use most (Pro tracks frequently used tools, and you can pin your own), and a Portal tab exposes web tools shared through your organization, which run on a server rather than your machine.
Two other doors are worth knowing about. First, many ribbon buttons
are secretly geoprocessing tools wearing nicer clothes — the overlay and
proximity buttons, the summarize commands on a table, and much of the
Analysis ribbon simply open pre-filled tool dialogs.
Second, right-clicking layers and fields often offers context commands
("Summarize", "Export Features") that are also tools underneath.
Everything funnels through the same framework, which is why everything
shows up in the same history.
Open any tool and you get a form in the Geoprocessing pane. The anatomy is the same everywhere, so learn it once.
Required parameters are marked (a small red
asterisk) and the tool will not run without them. Optional
parameters sit below, often collapsed into groups you can
expand. The input parameter accepts either a layer from your open map
(pick it from the drop-down) or a dataset on disk (click the browse
button next to the drop-down). The output parameter is pre-filled with a
default name in your project's default geodatabase — a "geodatabase"
being Esri's container format for spatial data, covered back in Chapter
1 (How GIS Thinks). You can and usually should rename that default
output to something a human can recognize next week.
Buffer_Roads_500m will make sense in March;
Roads_Buffer17 will not.
As you fill in the form, the dialog validates continuously. A yellow warning triangle next to a parameter means "this will run, but you should know something" — perhaps the inputs are in different coordinate systems and an on-the-fly transformation (a live reprojection applied during processing, without changing the stored data) will be used; see Chapter 3 (Coordinate Systems and Projections) for why that deserves your attention. A red error icon means the run is blocked until you fix the problem, and hovering on the icon tells you what the problem is. Read these. They are the framework trying to save you from yourself.
At the top of the dialog sit two tabs: Parameters
and Environments. The Environments tab is where you can
override environment settings for this one run only — more on
that in a moment. At the bottom sits the Run button; its
drop-down offers scheduling options for runs you want to repeat
automatically, and once a tool has run, its history entry can be
harvested as Python code — a thread picked up in the history section
below.
While a tool runs, a progress bar appears and you can keep working —
Pro executes geoprocessing without locking up the application. When it
finishes, a small completion banner appears at the bottom of the pane;
clicking View Details shows the full message log: what was
processed, any warnings raised, and how long it took. Warnings in this
log are worth skimming even when the run "succeeded", because
succeeded means "the tool did not crash", not "the answer is
what you meant to ask for."
Here is the section that pays for the whole chapter. Geoprocessing environments are settings that apply around a tool rather than inside it — they constrain where processing happens, what resolution it happens at, and what coordinate system the output lands in. They are enormously useful when used deliberately and quietly destructive when inherited by accident.
Environments live at several levels, and lower levels inherit from higher ones:
Analysis > Environments opens the project-wide settings.
Anything set here applies to every tool you run in this project
until you change it.The inheritance is the trap. Set an extent at the application level on Tuesday for one quick job, forget about it, and every tool you run on Thursday is still silently clipped to Tuesday's extent — with no error, no warning banner, nothing but a result that is mysteriously smaller than it should be.
The environments most likely to change your results without your noticing:
| Environment | What it controls | How it silently changes results |
|---|---|---|
| Extent | The rectangular area within which processing occurs | Raster outputs are clipped to the rectangle; vector features falling wholly outside it are excluded (features crossing the edge are typically processed whole, not cut). Either way, the tool reports success on the truncated area |
| Output Coordinate System | The coordinate system of new outputs | Outputs are reprojected on the fly; measurements and cell alignment shift, and downstream tools inherit the change |
| Cell Size | The pixel size of raster outputs | A coarse setting throws away detail; a fine setting invents precision that is not in the source and inflates processing time |
| Snap Raster | The raster whose cell grid new rasters align to | Without it, cell grids from different runs are offset from each other, so cell-by-cell comparisons quietly compare mismatched ground |
| Mask | An irregular area (a polygon or raster) limiting where cells get values | Everything outside the mask becomes NoData — raster-speak for cells that hold no value at all — correct when intended, baffling when inherited |
| Current Workspace / Scratch Workspace | Where outputs and temporary data are written by default | Outputs land somewhere other than where you are looking; you conclude the tool "didn't work" when it worked fine, elsewhere |
| Parallel Processing Factor | How many processor cores a tool may use | Affects speed rather than correctness — but it is the one to check when a big job crawls |
A concrete story, because this bites nearly everyone eventually. You run a watershed analysis zoomed in on one county, and — reasonably — set the processing extent to the current display so the test runs fast. It works. Two weeks later you run the full statewide analysis and the results look plausible: rasters render, statistics compute, nothing errors. Except every output stops at that county's invisible rectangle, and you do not discover it until someone asks why the northern half of the state has no data. The tool did exactly what it was told. You just forgot what you had told it.
Watch out: Environment settings persist with the project, survive restarts, and produce no warnings when they constrain a result. Before any analysis session that matters, open
Analysis > Environmentsand check three things: Extent, Output Coordinate System, and (for raster work) Cell Size, Snap Raster, and Mask. Blank generally means "derive sensibly from the inputs", which is usually what you want. If you only build one habit from this chapter, build this one.
Used deliberately, the same settings are power tools. Setting Extent to your study area keeps test runs fast. Setting Snap Raster and Cell Size to match a reference raster guarantees that every raster you derive stacks perfectly on top of it — essential for the cell-by-cell math in Chapter 19 (Terrain and Raster Analysis). Setting Output Coordinate System to your project's working projection means you never accumulate a folder of mixed-projection outputs. The point is not to fear environments; it is to never let them be a surprise.
Environments are the first source of silent result-shaping. Here is the second, and it is even easier to trip over: when you feed a layer into a tool, the tool honors whatever filtering that layer is carrying.
Two kinds of filtering matter:
status = 'Active'
will feed only active features into everything downstream until someone
remembers the query exists. Chapter 6 (Map Viewer: The Complete
Reference) covers the web equivalent; the behavior in Pro is the same
idea.The layer-versus-dataset distinction from earlier is the key. If you browse directly to the dataset on disk in the tool dialog, you get everything — no selection, no definition query, no joins. If you pick the layer from the drop-down, you get the layer's filtered view of the world. Neither is wrong; they are different questions, and you need to know which one you are asking.
Watch out: Before running any tool that matters, glance at the layer's attribute table — the count readout at the bottom shows both the total number of features and how many are currently selected. If the selected count is anything other than zero and you did not intend it, clear the selection first (the clear-selection command on the
Mapribbon does it globally). This five-second check prevents the single most common category of "my analysis is inexplicably wrong" support questions.
There is a third, subtler passenger: joins. If a layer has a table joined to it, some tools see the joined fields and some behave oddly with them. When a tool misbehaves on a joined layer, the standard remedy is to export the layer to a new dataset first — the export bakes the join, the selection, and the definition query into honest physical data, and the tool then has nothing hidden to trip on.
Every tool you run is logged in the geoprocessing history, reachable
from Analysis > History (it also appears in the Catalog
pane under the project's history section). Each entry records the tool,
every parameter value, the environment settings in effect, the start
time, the duration, and the complete message log — successes in one
list, failures with their error text preserved.
This is far more than an audit trail. The entries are live:
The history also feeds provenance — the recorded lineage of a dataset. Outputs written to a geodatabase can carry geoprocessing lineage in their metadata: which tool created them, from which inputs, with which settings. When you are evaluating whether to trust a dataset someone hands you (the theme of Chapter 5, Finding Data), lineage is one of the first things to look for; when you are the one publishing data, it is one of the kindest things you can leave behind.
Tip: Right-click any history entry and you will find an option to copy the run as a Python command — the exact call to
arcpy(Pro's Python library, Chapter 31), with all your parameters filled in as code. This is the single gentlest on-ramp to scripting that exists in Pro: run tools by hand until the workflow is right, then harvest the history into a script.
One caution: history is per-project. If your practice is to spin up throwaway projects, your lab notebook is scattered across them. For work that matters, keep the analysis in one project so the record stays in one place.
Sooner or later you will need to run the same tool on twenty inputs — buffer every one of these road files, clip every layer to the study area, convert a folder of tables. Running the dialog twenty times by hand is error-prone drudgery. Batch mode is the built-in answer.
Right-click a tool in the Geoprocessing pane and choose
Batch. Pro first asks which parameter should be the
batch parameter — the one that varies across runs, most often
the input dataset, though you can instead batch over a varying distance,
a varying field, or almost any other parameter. The tool dialog then
reappears with that parameter transformed into a list: add your twenty
inputs, fill in the remaining parameters once, and they apply to every
run.
Output naming is the part that needs thought. Twenty runs need twenty
distinct output names, so batch mode supports a substitution token — a
placeholder wrapped in percent signs, such as %Name% —
inside the output path, which expands to each input's name per run. An
output pattern along the lines of clipped_%Name% yields
clipped_roads, clipped_rivers,
clipped_parcels, and so on. Leave the output as a single
fixed name and each run overwrites the last (or fails, depending on your
overwrite setting); either way you will not finish with twenty
outputs.
Where does batch mode sit among its alternatives? A fair rule of thumb:
| Situation | Right tool |
|---|---|
| One tool, many inputs, run once | Batch mode |
| Several tools chained, reused occasionally, shared with non-programmers | ModelBuilder (Chapter 25) |
| Complex logic, scheduled runs, or anything you will maintain long-term | Python (Chapter 31) |
Batch mode is deliberately the shallow end: no logic, no chaining, just honest repetition. When you feel yourself wanting an "if" or a second step, you have outgrown it — graduate to a model or a script rather than fighting the format.
Real analysis is almost never one tool. A typical question — "how much residential land lies within a quarter mile of the proposed transit line?" — decomposes into a chain: buffer the line, clip the land-use polygons to the buffer, select the residential category, summarize the area. Volume D covers which tools answer which questions; what belongs here is the craft of running a chain by hand without losing your footing.
Name intermediates like you will be audited. Each
step produces an output that feeds the next step. Under deadline, the
temptation is to accept default names, and the result is a geodatabase
full of Buffer3, Clip_Output_4, and regret. A
naming pattern that encodes the step order and the operation —
s1_transit_buffer_quartermile, s2_landuse_clip
— costs seconds and repays hours.
Give intermediates a home. Two respectable patterns: keep everything, or keep nothing. If you keep everything, write intermediates into your project geodatabase with the disciplined names above, and you can re-inspect any step later. If you keep nothing, write intermediates to the memory workspace — Pro lets you direct outputs to a special in-memory location instead of disk — which is dramatically faster and evaporates when Pro closes. Memory is superb for steps you will immediately consume and never need again, and wrong for anything you might want tomorrow.
Tip: For a chain you are still figuring out, run each step against a small test area first — set the processing extent to a neighborhood-sized rectangle, sprint through the whole chain in minutes, sanity-check the logic, and only then clear the extent and run for real. Debugging on the full dataset means every mistake costs you the full runtime.
Verify between steps. After each tool, spend thirty seconds looking at the output before feeding it onward: open the attribute table, check the feature count against your expectation, glance at the geometry on the map. Errors compound quietly in a chain; a clip that returned zero features will happily flow into a summarize that reports zero area, and the final number will look authoritative.
Know when to stop chaining by hand. The hand-chained workflow is perfect for exploration and one-off questions. The moment a chain needs to run a second time — next quarter's data, the neighboring county, a colleague's request — rebuild it in ModelBuilder (Chapter 25), where the chain becomes a diagram you can rerun, share, and document, or harvest your geoprocessing history into Python (Chapter 31). Hand-chaining is for finding the path; models and scripts are for paving it.
Sooner or later you will search for a tool, find it, and discover its controls are locked or its run fails with a message about licensing. This is not a bug; it is the pricing structure showing through, and it helps to understand the shape of it without memorizing specifics.
ArcGIS Pro is sold at tiered license levels — conceptually a Basic, Standard, and Advanced ladder — and some geoprocessing tools require the higher rungs. The pattern is rough but real: everyday mapping and simple analysis sit at the bottom; multi-user editing and richer data management in the middle; and the most powerful overlay, statistics, and data production tools at the top. The tool documentation states the required level plainly, and a locked tool in the Geoprocessing pane will tell you what it needs.
Separately from levels, extensions are add-on products that each unlock a family of specialized tools:
| Extension | What it unlocks, conceptually |
|---|---|
| Spatial Analyst | Raster and cell-based analysis — surfaces, suitability modeling, hydrology, map algebra (arithmetic performed cell-by-cell across rasters) |
| 3D Analyst | Three-dimensional analysis — terrain, visibility, volumetrics |
| Network Analyst | Transportation problems — routing, service areas, allocation (Chapter 18) |
| Geostatistical Analyst | Advanced interpolation and prediction surfaces with error modeling |
| Image Analyst | Advanced imagery workflows — classification, deep learning, motion imagery (Chapter 15 territory) |
You can see which levels and extensions your account actually has on the Licensing page of Pro's application settings; your organization's administrator controls what is assigned to you (Chapter 34 covers that side). If a tool you need is locked, the practical options are, in order: check whether a similar tool at your license level does the job (there is often a humbler cousin), ask your administrator whether the extension can be assigned to you — many organizations own extension licenses that sit unassigned — or reformulate the analysis. What you should not do is assume the analysis is impossible; licensing walls are walls around tools, not around questions.
Most tools on most datasets finish before your coffee cools, and none of this section matters. Then one day you feed a tool a few million features or a statewide raster, watch the progress bar stall, and need a strategy. In rough order of payoff:
Work locally. Geoprocessing against data on a network drive or a slow connection can be many times slower than against the same data on your machine's own drive. For heavy jobs, copy the inputs to a local geodatabase first, run the analysis, and copy results back. The copy time is almost always repaid.
Subset before you process. The fastest features to process are the ones you exclude. If your question concerns one county, clip or select down to that county first, then run the expensive tools on the subset — rather than running the expensive tools statewide and subsetting the answer. The processing-extent environment does this for one run; a physical clip does it durably for a whole chain.
Prefer the pairwise generation of tools. Several classic overlay and proximity tools have modern siblings with "Pairwise" in the name — Pairwise Buffer, Pairwise Clip, Pairwise Dissolve, and kin — built to process in parallel across processor cores. On large inputs they can be dramatically faster. Their outputs can differ from the classic tools in small documented ways, so skim the tool help, but for big data they should be your default.
Use the memory workspace for intermediates. As noted above, writing intermediate steps to memory instead of disk removes the slowest part of many chains — the writing. Final outputs still belong on disk.
Index what you query. If a chain repeatedly selects by an attribute, an attribute index on that field speeds every query; spatial indexes (maintained largely automatically on geodatabase data) do the same for spatial operations. Indexing is a data-design topic — Chapter 12 (Schema Design) covers it — but its performance consequences land here.
Fix the data before blaming the tool. Corrupt or malformed geometry makes tools slow, flaky, or wrong. If a big job fails partway with geometry complaints, run a geometry check-and-repair pass first; Chapter 14 (Data Quality) covers the workflow.
Let it finish. Background processing means Pro stays usable during a long run, and the history records timing so you learn what "normal" is for your data. If you must stop a run, cancel it through the interface and wait — killing Pro outright mid-write is how geodatabases end up with half-written outputs that confuse everyone later.
Watch out: The progress bar is not a promise. Some tools cannot estimate their work accurately, and a bar that sits at ninety-something percent for a long time is often still working, not hung. Check the details view for message activity, and check your machine's disk and processor activity, before concluding a job is dead. Patience has rescued many analyses that a hasty force-quit would have corrupted.
The framework, the environments, the history, the invisible inputs — these are the mechanics beneath every analysis chapter that follows. When a result surprises you anywhere in Volume D, come back here first: check the environments, check the selection, read the messages, and consult the history. In geoprocessing, the tool is almost never lying to you; it is answering, with perfect obedience, a slightly different question than the one you thought you asked.
Map Viewer's Smart Mapping, covered in Chapter 7, is a guided experience: it looks at your data and offers sensible styles. ArcGIS Pro's symbology engine is the opposite philosophy. It offers you nearly total control and assumes you know what you want. That control is why professional cartographers do their serious work in Pro: every stroke width, every color ramp, every label's position on the page can be dictated, saved, and reused. This chapter is the map from "I can pick a color" to "I can build a road network that draws like a printed atlas."
Two ideas organize everything here. First, symbology — the rules that decide what each feature looks like — is chosen from a small set of symbology classes (single symbol, unique values, graduated colors, and so on), and then refined by editing the symbols themselves, which in Pro are layered constructions you can take apart. Second, labeling — the text the software places next to features — is run by a placement engine that resolves thousands of competing demands for space, and you steer it with classes, priorities, and weights rather than by dragging text around. Master those two systems and the rest of Pro cartography is detail.
Select a layer in the Contents pane (the panel listing your map's
layers, usually docked on the left — see Chapter 21 for the full tour of
Pro's interface). Two things happen: a contextual Feature
Layer ribbon appears at the top of the window, and the layer
becomes the target for symbology commands. The main entrance is the
Symbology pane: open it with
Feature Layer > Symbology on the ribbon, or by
right-clicking the layer and choosing Symbology. You can
also click any symbol swatch directly in the Contents pane to jump
straight into editing that one symbol.
The Symbology pane has more in it than first appears. Across its top runs a row of small tab buttons: the primary symbology (the main rules), a tab for varying symbology by attribute (secondary visual effects layered on top — this is also where scale-based symbol sizing lives), a tab for symbol layer drawing (draw-order control within the layer), and an advanced-options tab (sample-size limits for statistics on large datasets, and similar housekeeping). Most people only ever touch the first tab. The other three are where much of this chapter happens.
The first choice in the Symbology pane is a drop-down of symbology classes. Each is a different answer to the question "how should the data drive the appearance?" Here is the full menu, with the decision each one serves:
| Symbology class | What it does | Use it when |
|---|---|---|
| Single Symbol | Every feature looks identical | The layer is one kind of thing (all rivers, all parcels) and location alone is the message |
| Unique Values | One symbol per category value | A text or coded field divides features into kinds (zoning class, road type) |
| Graduated Colors | Numeric values grouped into classes, each class a color | Showing "how much" across polygons — rates, percentages, densities |
| Graduated Symbols | Numeric values grouped into classes, each class a symbol size | Showing "how much" at points or along lines with size instead of color |
| Proportional Symbols | Symbol size scales continuously with the value | You want exact magnitudes, not class buckets |
| Unclassed Colors | A continuous color ramp with no class breaks | You want the smooth version of graduated colors |
| Bivariate Colors | A grid of colors encoding two numeric fields at once | Exploring how two variables relate spatially (income vs. rent burden) |
| Dot Density | Random dots inside polygons, each dot worth N of something | Showing distribution and quantity together (population, crop acreage) |
| Charts | A small pie or bar chart on each feature | Comparing the composition of several fields per feature |
| Heat Map | Points rendered as a smooth density surface | Thousands of overlapping points where individual dots are unreadable |
A few of these deserve more than a table row.
Unique values is the workhorse for categorical data. Point it at a
field and Pro lists every distinct value with a symbol beside it. You
can group several values under one symbol (useful when a field has
twelve road classes but your map only needs four visual tiers), reorder
the legend, and add more fields to symbolize on combinations of values.
The quality of a unique-values map depends almost entirely on your
schema: a clean coded-value domain — a locked pick-list of allowed
values (see Chapter 12, Schema Design) — produces a clean legend; a
free-text field produces a legend with Residential,
residential, and Res. as three separate
classes.
Graduated colors is the classic choropleth — a map where areas are shaded by a value. The consequential decision is not the color ramp but the classification method: how the range of values gets chopped into classes. Natural breaks looks for gaps in the data; quantile puts an equal count of features in each class; equal interval slices the range evenly; standard deviation classifies by distance from the mean; manual lets you set the break values yourself; a couple of specialized methods (defined interval, geometric interval) round out the menu. The same data can tell noticeably different stories under different methods, so treat the choice as an editorial act, not a default to accept. Chapter 4 (Cartographic Design) covers when each method is honest and when it misleads; Chapter 17 covers the statistics underneath.
Watch out: Graduated colors on raw counts is the most common thematic-mapping mistake. Big polygons usually contain big counts simply because they are big. Normalize — divide by area or population using the normalization setting in the pane — or switch to dot density, which shows raw counts honestly.
Graduated symbols and proportional symbols both encode quantity as size. The difference is classing: graduated symbols use a handful of discrete sizes, which makes the legend easy to read; proportional symbols scale continuously, which is more truthful but harder to eyeball. For most audiences, a few well-chosen classes communicate better than mathematically pure scaling. Unclassed colors is the same trade-off applied to color: a continuous ramp with a two-ended legend instead of class boxes.
Bivariate symbology blends two color ramps into a grid — typically three-by-three — so each feature's color encodes its position on both variables at once. Done well, it reveals relationships a pair of separate maps would hide: the corner cells of the grid mark places that are high on both measures or high on one and low on the other. Done carelessly, it produces a map nobody can decode. Keep the grid small, choose the built-in color schemes rather than inventing your own, and always include the two-axis legend Pro generates.
Dot density scatters dots randomly within each polygon, with each dot representing a fixed quantity you choose. It is one of the few techniques that shows raw counts fairly, and it conveys texture — dense clusters read as dense places. Because the dots are placed randomly within polygons, do not let readers infer that any individual dot marks a real location. Dot density is also sensitive to the map's projection: use an equal-area projection (Chapter 3) or the visual density will lie.
Chart symbology draws a miniature pie or bar chart on each feature from several numeric fields. It is occasionally the right tool — comparing the makeup of something across a few dozen features — but charts clutter quickly. If you are tempted to put pie charts on two hundred counties, a set of small side-by-side maps almost always communicates better.
Heat map symbology turns a dense point layer into a smooth color surface of relative density. It recalculates as you zoom, which makes it excellent for exploration and screen maps, and unsuitable for any claim that requires stable, quantified values — for that, run an actual density analysis (Chapter 17) and symbolize the resulting raster.
Choosing a symbology class decides which features get which symbol. The symbols themselves are a separate, deeper system. Click any symbol swatch in the Symbology pane and you enter the symbol editor, which has two faces: a Gallery tab of ready-made symbols from your loaded styles, and a Properties tab where you can rebuild the symbol from parts.
The central idea is that every symbol in Pro is a stack of symbol layers. Not layers in the map sense — layers inside a single symbol, drawn bottom-to-top:
The classic demonstration is a highway symbol. A printed-atlas highway is not one line — it is a wide dark stroke with a narrower light stroke drawn on top, producing a colored road with a dark edge (cartographers call the edge a casing). In Pro you build it as exactly that: open the symbol's Properties tab, look at the layer list, and add a second stroke layer. Set the bottom stroke a couple of points wider than the top one, color the bottom dark and the top light, and you have a cased road. Add a dashed white stroke above those and you have painted lane lines.
Tip: Symbol layers accept effects — geometric transformations applied before drawing, such as dashes, offsets, arrows, buffers, and waves. A one-sided offset stroke makes a cliff or depression symbol; a dash effect with a marker placed on each dash makes a railway. Browse the effects list before assuming you need to digitize decoration by hand.
Two practical settings matter more than any of the fancy options. First, units: symbol sizes are normally set in points (a fixed size on screen or paper, no matter the zoom), but you can size symbols in real-world map units so they grow and shrink with the ground — right for things like buffer rings that represent real distances, wrong for almost everything else. Second, color locking: in unique values symbology, you can lock individual symbol layers so that applying a new color scheme recolors only the unlocked layers — letting you recolor a hundred category fills at once while every casing stays dark gray.
Layers in the Contents pane draw bottom-to-top, and within a single layer, features draw in whatever order the database returns them. Usually you never notice. You notice the moment two cased roads cross: the casing of the road drawn second slices across the fill of the road drawn first, and the intersection looks like a collision instead of a junction.
Symbol layer drawing (the feature historically called symbol levels) fixes this by changing the drawing order from feature by feature to symbol layer by symbol layer. Instead of "draw all of road A, then all of road B," the layer draws "all casings first, then all fills." Where two roads of the same class cross, their fills now sit together on top of both casings, and the junction merges into a continuous surface — the way road atlases have always drawn it.
You enable it on the Symbology pane's symbol layer drawing tab: switch it on, and Pro lists every symbol layer in the layer's symbology so you can drag them into an explicit drawing order. The usual arrangement for a road network is all casings at the bottom, then fills ordered by road importance, so that highways visually pass over local streets.
Watch out: Symbol layer drawing changes only how the map draws, not the data. If an overpass genuinely crosses above another road, drawing order alone cannot know that — you need an attribute recording the level of each segment, and symbology or definition queries (filters that control which features a layer draws at all) driven by it. Also note that once symbol layer drawing is on, the layer ignores the normal per-feature ordering, which can surprise you if you were relying on it.
The primary symbology answers one question about each feature. The Vary symbology by attribute tab lets the same layer answer more, by binding additional attributes to secondary visual channels on top of whatever primary class you chose:
Each of these accepts either a field or an Arcade expression — Esri's small scripting language for computing values on the fly, covered start to finish in Chapter 8 — so the driving value does not have to exist as a column. Restraint is the skill here: each added visual variable multiplies what a reader must decode. Two channels (color plus size) is a rich map; four is homework.
A map that will be viewed across many zoom levels cannot wear one outfit. Pro gives you several tools, from blunt to fine:
Visibility ranges are the blunt tool: in the layer's
properties or on the Feature Layer ribbon, set the scales
between which the whole layer draws at all. Local streets simply should
not exist at a statewide scale.
Scale-based symbol sizing is the finer tool, found on the Symbology pane's vary-symbology-by-attribute tab for most symbology types. You define the map scales you care about as stops and set a symbol size at each; Pro interpolates between them. A city point can be a subtle dot at small scales and a bold marker up close, without maintaining duplicate layers.
Alternate symbols go further for unique values symbology: a category can carry entirely different symbols for different scale ranges — an airport that is a simple circle when zoomed out and a detailed runway pictogram when zoomed in.
This is the same "one map, many scales" discipline behind multiscale web maps; if your destination is a hosted layer rather than a printed page, read this alongside Chapter 10's discussion of how scale affects hosted feature layer performance.
Labeling is the part of cartography most people underestimate. Placing one label is trivial. Placing eight thousand labels so that none overlap, the important ones survive, roads read along their curves, and cities sit clear of the coastline — that is a hard optimization problem, and Pro ships a dedicated engine for it. The engine is called Maplex, and in Pro it is the default (an older, simpler engine — the Standard label engine — survives as a compatibility option; there is little reason to seek it out). You do not program Maplex. You describe your intent — what to say, where you would prefer it, what matters most, what may be sacrificed — and the engine computes a solution every time the map redraws.
Select a layer and open the Feature Layer > Labeling
ribbon tab (or right-click the layer and choose Label). One
click and the engine starts placing text from the layer's display field.
The ribbon then exposes the essentials: which field or expression
supplies the text, the text symbol (font, size, color, and halo — the
contrasting outline that keeps text readable over busy backgrounds), the
visibility range for labels, and the placement style.
The label text does not have to be a raw field. A label expression — written in Arcade — can combine fields, format numbers, add line breaks, or change wording conditionally: a peak labeled with its name and elevation, a parcel labeled with its ID only when a status field says it is active. Chapter 8 teaches the language; Chapter 9 covers the equivalent (and more limited) labeling controls in Map Viewer.
A label class is a rule bundle: a subset of features
(defined by a SQL query — an attribute filter such as
RoadClass = 'Highway'), an expression, a text symbol, a
placement configuration, and a visibility range. Every labeled layer has
at least one, and the real power is having several. A roads layer might
carry three: one class labeling highways with a shield-style marker at
all scales, one labeling arterials in medium gray at mid scales, one
labeling local streets in small type only when zoomed far in. Each class
is configured independently, and together they behave like a typographic
hierarchy — which is exactly what Chapter 4 says a good map needs.
Placement is where Maplex earns its keep, and the options differ by geometry:
When labels compete for the same space — and on any dense map they
always do — the engine consults two rulebooks you control, both
reachable from the Labeling ribbon's map-wide options:
Label priorities rank every label class in the map. When two labels want the same pixels, the higher-priority class wins and the loser tries an alternate position or drops out. This single ranked list is the closest thing the map has to an editorial policy: put city names above street names, street names above parcel IDs, and the engine enforces it thousands of times per redraw.
Weights protect map features from being overprinted. A feature weight tells the engine how bad it is to place any label on top of that layer's features: give your road casings a high weight and labels will avoid lying across roads; give a background land-use layer zero weight and labels will happily cover it. Label weights, similarly, govern how firmly placed labels resist being overlapped by others.
Beyond dropping labels, Maplex has gentler fitting strategies, configured per label class: stacking a long name onto multiple lines, letting a street label overrun its segment slightly, compressing or shrinking the font within limits you set, and abbreviating words from a dictionary you supply. Each is a controlled concession that keeps a label on the map instead of losing it.
Tip: For the labels that must never disappear — the map's title features, the city the whole map is about — the placement properties include a "never remove" option. Use it sparingly: every unremovable label removes the engine's freedom somewhere else, and three of them fighting each other can wreck a neighborhood of the map.
Configure labels with the map at (or near) its final scale, and set a reference scale on the map (in the map's properties) when your destination is print. The reference scale freezes the relationship between symbol and text sizes and the ground, so everything scales together on the layout instead of re-flowing. Chapter 24 (Layouts, Map Series, and Print Cartography) picks this thread up in detail.
Labels are computed fresh on every redraw; you influence them but never place one by hand. Annotation is the opposite: text stored as actual features in a geodatabase, each piece with its own position, its own editable properties, and no engine deciding anything. You typically create annotation by converting a layer's labels — right-click the map in the Contents pane and look for the convert-labels-to-annotation command — which snapshots the engine's current solution into features you can then nudge, rotate, and reword one by one.
| Labels | Annotation | |
|---|---|---|
| Placement | Computed by the engine each redraw | Fixed; each piece stored and edited individually |
| Hand adjustments | Not possible per label | The entire point |
| Reacts to data edits | Automatically | Only feature-linked annotation follows its feature |
| Scale behavior | Reflows and re-resolves at every scale | Frozen at a reference scale; degrades away from it |
| Best for | Web maps, dynamic maps, early drafts | Final print cartography needing perfect placement |
Feature-linked annotation is the hybrid: each text feature is tied to a source feature through a geodatabase relationship, so renaming a road updates its annotation text (position stays where you put it). It requires a geodatabase and a bit of schema care — Chapter 12 territory.
Watch out: Converting to annotation is a one-way editorial decision. The moment you convert, new features in the layer get no text (feature-linked annotation is the exception — it generates text for new features), attribute edits stop flowing into non-linked annotation, and the label engine's configuration is abandoned. Convert late — after the data is stable and the map design is locked — or you will hand-maintain text forever.
Everything you have built in this chapter — layered road symbols, a
tuned color scheme, a north arrow you actually like — can be saved and
reused. The container is a style file: in Pro, a single
portable .stylx file, a searchable database of symbols,
colors, color schemes, text symbols, and layout elements (styles from
ArcMap's older .style format can be imported). Pro ships
with system styles; you add more, including your own, through
Insert > Styles on the ribbon or the Styles section of
the Catalog pane. Once a style is added to the project, its contents
appear in every symbol Gallery, searchable by name and tags.
Saving into a style is a right-click away wherever you finish crafting something: save the current symbol to a style from the symbol editor, and it becomes a gallery item your whole team can use if you keep the style file in a shared location. An organization style file — your agency's road symbols, your company's brand colors as named color schemes, standard text symbols for titles and sources — is one of the highest-leverage cartographic assets a team can own, because it turns "match the house look" from an afternoon of fiddling into a gallery click.
Styles store parts. To reuse a whole configured layer —
symbology class, symbol assignments, label classes, visibility ranges,
the lot — save a layer file (.lyrx) by
right-clicking the layer and choosing the save-as-layer-file command
under its sharing options. A layer file records the presentation and a
pointer to the data, so dropping it into any map reproduces the finished
look. For web work, the analogous move is publishing the styled layer
and letting others use it as-is; Chapter 10 covers how symbology travels
(and what gets lost) when Pro layers become hosted layers.
Tip: Add a "favorites"-style personal collection early and throw every symbol you tweak into it, even half-finished ones. Symbol construction is fiddly enough that your past self is your best supplier.
The controls in this chapter reward a particular order of operations. Decide the story first and pick the symbology class that tells it. Get the classification and fields right before touching colors. Build symbols as layered constructions and turn on symbol layer drawing the moment line work starts crossing. Add labels only once the symbology is stable, structure them as classes with an explicit priority ranking, and let the engine work before overriding it. Convert to annotation last, if at all. And every time you finish something good, save it to a style — the second map is where this engine starts paying you back.
Everything you have done in ArcGIS Pro so far has happened inside a map view — a window onto your data that stretches to fill whatever screen it is on, pans forever in every direction, and redraws itself at any scale you like. A printed map is the opposite of all that. It has fixed edges. It has one scale, or a small set of them. Nobody can click a feature to see its pop-up, so everything the reader needs must be visible in ink. The tool Pro gives you for crossing that gap is the layout: a virtual sheet of paper onto which you place one or more windows into your maps, plus all the supporting furniture — legend, scale bar, title, north arrow, source notes — that lets the map stand on its own.
This chapter covers the whole journey: building a layout, controlling map frames and insets, mastering the surrounds (the legend most of all), using dynamic text so your layouts update themselves, turning one layout into an entire map book with map series, and choosing the export settings that decide whether your PDF looks crisp or muddy. How to make the map inside the frame beautiful is the territory of Chapter 4 (Cartographic Design) and Chapter 23 (Symbology and Labeling: The Pro Engine); this chapter is about the page around it.
A layout in Pro is a separate item inside your project, alongside your maps. One project can hold many maps and many layouts, and any layout can display any of the project's maps — the connection between them is a map frame, which we will get to shortly. This separation is the single most important mental model in this chapter: the map is the content; the layout is the presentation of that content on a page. You can have one map presented on three different layouts (a letter-size handout, a large wall poster, a slide-shaped export for a presentation) without duplicating any data or symbology.
To create one, go to Insert > New Layout on the
ribbon. Pro offers a gallery of page sizes — the familiar letter and
tabloid sizes, the international A-series (A4, A3, and so on), and
large-format architectural sizes for plotters — each in portrait or
landscape orientation. Pick the size you will actually print at. This
matters more than it seems: text that is comfortably readable on a
letter page becomes microscopic if you design at poster size and later
shrink the export, and symbols sized for a poster look clownish squeezed
onto letter paper. Design at final size, always.
The layout opens as a new view tab showing a white page against a gray backdrop. A few pieces of the workspace are worth setting up before you place anything:
Tip: Before placing a single element, drag out guides for your margins — a half inch to an inch on all sides is a common starting point for desktop printers, which cannot print to the paper's edge. Everything you place should live inside that margin box. Retro-fitting margins onto a finished layout is miserable; setting them first takes thirty seconds.
If you need to change the page size later, look for the page setup
controls on the Layout ribbon tab. Pro will keep your
elements where they are, which usually means you will be rearranging
things — another reason to choose the final size first.
A map frame is a rectangle (or circle, or other
shape) on the page that displays a live view of one of your project's
maps. Insert one from Insert > Map Frame — the dropdown
shows each map in your project along with its bookmarks, so you can
place a frame already pointed at a saved extent. Then drag a rectangle
on the page to size it.
The crucial skill with map frames is knowing the difference between selecting the frame and working inside it:
Activate, or use the Activate button on the
Layout ribbon): now you are inside the map. Pan
and zoom work exactly as they do in a map view, and you are changing
what geography the frame shows, not where the frame sits on the page. A
highlighted border and a small heading indicate you are in activated
mode; a back arrow near the top of the view returns you to the
page.Beginners lose real time to this distinction — nudging a frame when they meant to pan the map, or wondering why the map will not pan when the frame is merely selected. Once the two modes click, layout work speeds up dramatically.
By default a map frame is a free window — activate it and pan wherever you like. But a print map usually needs its extent pinned down, and Pro gives you a spectrum of constraints in the map frame's properties (right-click the frame and open its properties, then find the extent settings):
| Constraint | What stays fixed | When to use it |
|---|---|---|
| None (linked to map view) | Nothing — the frame follows interaction | Early drafting, exploring compositions |
| Fixed center | The center point; scale can change | Rarely — niche use |
| Fixed scale | The scale; you can still recenter | Map series where every page must be the same scale |
| Fixed extent | Everything — the frame is locked | Final production; nothing can drift before export |
Setting a fixed extent just before final review is a professional habit: it guarantees that a stray scroll of the mouse wheel does not silently shift your map between the version you proofed and the version you exported.
You can also type an exact scale into the scale box at the bottom of the layout view while the frame is activated or selected. Print maps should use round, honest scales — 1:24,000, 1:50,000, 1:100,000 — rather than whatever odd number zooming happened to land on. A scale of 1:63,417 tells the reader you did not think about it.
Nothing limits a layout to one map frame, and the two classic multi-frame patterns are worth mastering:
The locator inset (also called an overview map) is a small frame showing where the main map sits within a larger, familiar geography — a county highlighted within its state, a neighborhood within its city. Readers orient themselves with it in a glance. The clean way to build one is to create a separate map in your project for the locator — simple, drawn at a small scale (zoomed well out), minimally labeled — and give it its own frame on the layout, usually tucked into a corner of the main frame with a solid background so it reads as deliberate rather than accidental.
The detail inset is the reverse: a zoomed-in frame magnifying a congested area — a downtown core on a county map, a cluster of sample sites too dense to label at the main scale. Detail insets can display the same map as the main frame at a different scale, which keeps symbology automatically consistent between the two.
When you have a locator or detail inset, the reader needs to see the relationship between frames — where, exactly, does the main map sit inside the locator? An extent indicator draws that answer automatically: a rectangle (or the actual footprint shape) in one frame showing the extent of another frame, live-linked so it moves if the other frame's extent changes.
Extent indicators belong to the frame that displays them.
Select the locator frame, and in its properties or via the
Insert ribbon find the extent indicator options; add one
that points at your main map frame. You can style the rectangle's
outline and fill, and for indicators that would be too small to see at
the locator's scale, Pro can collapse them to a point marker or add a
leader line. Because the link is live, you never have to redraw the
little red box by hand after recentering the main map.
Cartographers call the supporting elements around the map
surrounds or map furniture: legend,
scale bar, north arrow, title, source and credit text, grids. Pro treats
each as an element you place from the Insert ribbon, and
the good news is that most of them stay dynamically linked to
the map frame they describe — change the map and the furniture updates
itself.
The legend is the hardest-working surround and the one with the deepest settings.
Insert one from Insert > Legend, then drag a box on
the page. Pro builds the legend from the layers in the map frame you
associate it with, using each layer's name and its symbology classes —
which means the legend is only as good as your layer names and class
labels. "roads_clip_final_v3" in the Contents pane becomes
"roads_clip_final_v3" in the legend. Rename layers and edit class labels
in the map first (see Chapter 23); the legend inherits the cleanup
automatically.
Each entry in a legend is a legend item, and each item has its own properties: whether to show the layer name, the headings, the class labels; the shape and size of the patch (the little swatch of symbol next to each label — you can switch an area patch from a rectangle to a shape that suggests the feature, like a water-body squiggle for lakes); and spacing between all the parts. Select the legend and work through its properties pane, or expand the legend in the layout's Contents pane to reach individual items.
The settings that separate an amateur legend from a professional one:
Watch out: Pro can convert a legend to plain graphics so you can freely edit every label and swatch. It is a one-way door — the converted legend never updates again, no matter how the map changes beneath it. Exhaust the legend item settings first, and convert only as a last resort on a truly final layout. If you must do it, save a copy of the project first.
Screens have zoom; paper does not — so print maps carry a
scale bar, a ruled line showing how page distance
translates to ground distance. Insert one from
Insert > Scale Bar, choosing from a gallery of styles,
and it links to a map frame and updates automatically when the frame's
scale changes.
The properties worth adjusting: the units (miles for a US road-trip audience, kilometers for scientific or international work — or both, one bar above the other); the number of divisions and whether the first division is subdivided for finer reading; and crucially the resize behavior — you can tell Pro to keep the bar a fixed width and adjust the division values, or keep round-number divisions and let the width adjust. Round numbers win: a scale bar reading 0–1–2–4 kilometers is usable; one reading 0–1.37 kilometers is decoration.
A scale text element ("1:50,000") can accompany or replace the bar. Ratio text is precise but demands mental arithmetic from the reader; the bar is what most people actually use. Small maps for a general audience can carry the bar alone.
Watch out: A scale bar tells the truth only where the map's projection preserves distance — and no flat map preserves distance everywhere. On a city or county map the error is negligible. On a map of a continent, a single scale bar can be wildly wrong away from where the projection is tuned, which is why zoomed-far-out world maps often omit one entirely. Chapter 3 (Coordinate Systems and Projections) explains which projections distort what; let it guide whether your scale bar is honest.
Insert one from Insert > North Arrow. Two pieces of
judgment apply. First, restraint: the gallery includes ornate compass
roses that overwhelm a modest map — a small, quiet arrow serves almost
every layout better. Second, necessity: if your map has a labeled
graticule (a latitude–longitude grid, covered below), or north is
unambiguous and up, the arrow may be redundant. Where you do include
one, know that "north" is not one thing: true north
points to the geographic pole, while grid north follows
the vertical lines of your projected coordinate system, and the two
diverge as you move away from the projection's central meridian (the
line of longitude the projection is centered on). Pro's north arrow
properties let you pick which one the arrow tracks; for most layouts the
default is fine, but on large-format engineering or survey sheets the
distinction is load-bearing.
A grid is a network of reference lines drawn over
the map frame with labeled edges, letting a reader pin down locations by
coordinate. Pro offers three everyday families, added through the map
frame's properties (look for the grids section) or from the
Insert ribbon while the frame is selected:
| Type | Lines follow | Labels read as | Typical use |
|---|---|---|---|
| Graticule | Latitude and longitude | Degrees (and minutes/seconds) | Small-scale and regional maps; nautical and aviation traditions |
| Measured grid | The projected coordinate system's easting/northing (its east and north distance coordinates) | Meters or feet | Topographic and engineering sheets |
| Reference grid | Arbitrary equal cells | Letters and numbers (A3, F7) | Street atlases and indexes ("see cell C4") |
A specialized fourth option implements the military grid reference system (MGRS) for defense and search-and-rescue work — a formalized cousin of the measured grid.
Each grid is deeply configurable — line symbols, tick marks instead of full lines across the map, label fonts and edge placement. Interior lines can clutter a busy map; a common compromise is ticks or crosses at intersections with labels only along the frame edge. Most everyday layouts need no grid at all. Add one when readers will genuinely use coordinates — navigation, field reference (see Chapter 30 for field operations), or atlas lookup — not as ornamentation.
Dynamic text is text whose content Pro fills in for
you from live properties of the project, the page, or a map frame. Under
the hood it is a text element containing a tag — a placeholder
in angle brackets — that Pro evaluates at draw time. Insert ready-made
pieces from the dynamic text gallery on the Insert ribbon,
or type tags into any text element yourself.
The categories that matter in practice:
Dynamic and static text mix freely in one element: "Prepared by the
Planning Department — data current as of
Tip: Build the habit of putting three quiet lines of dynamic text on every serious layout: data credits from the map frame, the export date, and the spatial reference name. They cost nothing, they never go stale, and the day someone asks "which projection is this, and how old is the data?" the map already answers.
Suppose you need a map of every one of a county's forty voting precincts — same design, same layers, different extent and title on each sheet. Building forty layouts would be absurd. A map series builds them from one: you design a single layout, point it at an index layer — a feature layer whose features define the pages — and Pro generates one page per feature, driving the map frame's extent from each feature's shape and the page's text from each feature's attributes.
Enable the series from the Layout ribbon tab — look for
the map series controls in the page setup area, and choose a
spatial map series. You will identify:
If no natural index layer exists — you simply want to tile a large area across pages — geoprocessing tools exist to generate one: a rectangular grid of index polygons sized to your page and scale, or a strip-map index that follows a linear feature like a highway or pipeline, producing pages that march along the route (and can even rotate the frame to follow it). Search the geoprocessing toolboxes for grid index and strip map index tools; Chapter 22 (Geoprocessing in Depth) covers how to find and run tools generally.
With the series enabled, a panel lists every page, and clicking one redraws the layout for that feature — this is how you proof. The features that turn a mechanical series into a polished map book:
Besides spatial series, Pro also offers a bookmark map series — one page per saved bookmark rather than per index feature — a quick path when your "pages" are a handful of hand-chosen views rather than a wall-to-wall tiling.
Tip: Proof a map series by checking its three worst pages, not its best. Find the geographically largest index feature (does the scale still work?), the smallest (does the page look empty?), and the one with the longest name field value (does the title overflow?). If those three pages hold up, the middle thirty-seven almost certainly do.
When you export a layout that has a series enabled (see the next section for the mechanics), the export dialog grows series options: all pages, the current page, a page range, or a selection. You can write everything into a single multi-page PDF — the usual choice for a map book — or emit one file per page, with the page name woven into each filename. Multi-hundred-page series take real time to export; this is a natural job to hand to Python once you are doing it monthly (Chapter 31).
A layout becomes a deliverable through
Share > Export Layout (printing directly works too, but
exporting to a file first — then printing the file — gives you a
proofable, archivable artifact, and it is what a print shop will ask for
anyway). PDF is the default format and the right one for nearly all
print work; it preserves vector artwork, embeds fonts, and every print
shop on earth accepts it. Image formats (PNG, JPEG, TIFF) have their
place for slides and web embedding, but this section focuses on the
settings that decide print quality, most of which live in the PDF export
pane.
DPI — dots per inch — sets the resolution at which raster content in your layout is written into the file: basemap tiles, imagery, hillshades, and anything the exporter is forced to rasterize. It does not affect genuinely vector content, which stays resolution-independent. Common practice: a modest DPI for on-screen review copies, and a high setting — in the neighborhood printers conventionally ask for, around 300 — for production printing. Higher values inflate file size quickly, and beyond what the printing device can physically resolve they buy nothing. If a print shop is involved, ask what they want; they always have a number.
A vector PDF stores your linework, polygons, and text as geometric instructions — infinitely zoomable, crisp at any size, and text remains selectable and searchable. A raster PDF is essentially a photograph of your layout at a fixed resolution. The export output-quality settings control which you get, and you should insist on vector output for print cartography whenever possible.
The catch is that certain map effects force rasterization even in a "vector" export. Transparency is the classic culprit: a semi-transparent layer blended over a basemap generally cannot be described in pure vector terms, so the exporter flattens some or all of the affected content to an image at your chosen DPI. Certain advanced symbol effects behave similarly. The result is legal and printable — but text that gets caught in a rasterized region turns fuzzy, and file sizes balloon.
Watch out: If your exported PDF looks soft or its text will not select, transparency somewhere in the map has forced rasterization. Zoom far into the PDF: vector line-work stays razor-sharp, rasterized areas dissolve into pixels. The fix is upstream, not in the export pane — replace transparent fills with pre-mixed opaque colors (hatched or tinted equivalents) in the map's symbology, then re-export. Chapter 23 covers the symbology side.
Screens make color by emitting red, green, and blue light (RGB); presses make it by layering cyan, magenta, yellow, and black ink (CMYK). The two systems cannot reproduce identical ranges of color, so a map designed in RGB shifts — sometimes subtly, sometimes dramatically in the saturated blues and greens maps love — when converted to ink. Pro's PDF export can write CMYK output; for anything going to a commercial press, ask the shop whether they want CMYK from you or prefer to convert your RGB file themselves, and believe their answer over any general rule. For office laser printers and home inkjets, standard RGB export is fine — their drivers handle conversion. If exact color matters (an agency brand color, a published map standard), request a physical proof from the printer before the full run. The screen is never the proof.
A few more settings earn attention:
Finally, proof on paper. Print one copy at final size on the actual device (or order one proof from the shop) and read it at arm's length in decent light. Line weights that looked fine on a backlit screen routinely turn out too faint in ink; type that seemed adequate turns out one size too small. One test print catches what forty screen reviews miss.
The second time you build the same title block, you have waited one time too long to make a template. Pro gives you several layers of reuse:
.pagx file from the layout's context menu in the Catalog
pane) package the entire page — frames, surrounds, dynamic text, guides
— into a file you can import into any project via
Insert > New Layout (imported layouts appear alongside
the stock page sizes) or by dragging the file in. Map frames reconnect
to whatever maps the new project offers..aptx) go further,
bundling maps, layouts, styles, and connections into the starting point
for a whole class of projects — the standard package for, say, every
incident-response map your team produces. Chapter 21 (Pro: Interface,
Projects, and Settings) covers project anatomy.Design your templates with dynamic text doing the per-map work: a title tag, credit tags, date tags. Then "making the monthly map" collapses to open template, point frame at this month's map, export — and when even that is too slow, the export step scripts cleanly in Python (Chapter 31).
A closing rhythm for any print job, distilled: design at final size with margins as guides; lock the extent before proofing; let legends, scale bars, and dynamic text stay live-linked to the very end; export vector PDF at print-appropriate DPI; and proof once on real paper. Layouts reward exactly the kind of systematic care that map series and templates then multiply across every page you will ever print.
Somewhere in your GIS work there is a sequence you have run by hand more than twice: clip the parcels to the study area, buffer the streams, erase the buffer from the parcels, summarize what's left. Four tools, run in order, every time the data updates. ModelBuilder exists so you never have to run that sequence by hand again. It is a visual programming environment inside ArcGIS Pro where you chain geoprocessing tools together as a flowchart — boxes connected by arrows — and then run the whole flowchart with one click. The flowchart is the program. No code required, though as you'll see at the end of this chapter, ModelBuilder is also the best on-ramp to code you will ever find.
If Chapter 22 (Geoprocessing in Depth) taught you what individual tools do and how they behave, this chapter teaches you how to compose them into machines: reusable, parameterized, self-documenting machines that you can hand to a colleague as if Esri had shipped the tool themselves.
A model is a saved workflow diagram that lives inside a toolbox — the same container that holds Esri's own geoprocessing tools. When you save a model, it appears in the toolbox with its own icon, and anyone who opens it from the toolbox sees a normal tool dialog with input boxes and a Run button. They never need to know it's a flowchart underneath. This is the central promise of ModelBuilder: you build once on the canvas, and everyone else (including future you) consumes it as an ordinary tool.
Every ArcGIS Pro project comes with a default project toolbox, and
new models land there unless you choose otherwise. To start one, go to
Analysis > ModelBuilder on the ribbon. A blank canvas
opens as a new view, and a new ModelBuilder tab appears
on the ribbon with all the model-specific commands — this contextual tab
is your control panel for everything in this chapter.
Tip: Rename your model immediately. Right-click the model in the Catalog pane, choose
Properties, and give it both a name (the internal identifier, no spaces) and a label (the friendly title people see). A project full of models called "Model", "Model1", and "Model2" is a project you will not understand in six months.
The ModelBuilder canvas holds exactly three kinds of things, and everything you will ever build is made from them.
| Element | Shape on canvas | What it represents |
|---|---|---|
| Tool | Rectangle | A geoprocessing tool (Buffer, Clip, your own models too) |
| Data variable | Oval (blue for inputs, green for outputs) | A dataset — a feature class, table, raster, or layer |
| Value variable | Oval (lighter shade) | A non-dataset value — a number, a text string, a field name, an expression |
| Connector | Arrow | The flow of data or values from one element into a tool's parameter |
You populate the canvas by dragging. Drag a tool from the Geoprocessing pane's search results onto the canvas and it appears as a rectangle with an attached green output oval. Drag a layer from the Contents pane, or a dataset from the Catalog pane, and it appears as a blue input oval. To wire them together, hover over the edge of a data oval, then click and drag an arrow to the tool; ModelBuilder asks which of the tool's parameters the data should feed, and you pick one from a small list.
Color carries meaning beyond shape. Elements that are ready to run
are filled with solid color. Elements that are hollow (white inside) are
not ready — usually because a required parameter hasn't been supplied
yet. After a model runs, elements that executed successfully gain a drop
shadow, which is how you can tell at a glance what has and hasn't been
run. The Validate button on the ModelBuilder ribbon clears
all those shadows and re-checks every element's readiness, resetting the
model to a clean, ready-to-run state.
A few canvas mechanics worth knowing early:
Run. This is how you test a model piece by piece
instead of holding your breath through the whole chain.Tip: Build and test incrementally. Add one tool, wire it, run it, confirm the output looks right on the map, then add the next tool. A twelve-tool model built all at once and run for the first time is a debugging session waiting to happen.
There are two ways to run a model, and they behave differently in one important respect.
Running from inside ModelBuilder (the Run button on the ModelBuilder ribbon) executes the chain on the canvas, animates progress tool by tool, and leaves every output — including the in-between ones — sitting on disk where you can inspect them. This is the developer's view, meant for building and debugging.
Running from the toolbox (double-clicking the model
like any other tool) shows the clean tool dialog instead. In this mode,
outputs marked as intermediate are automatically
deleted when the run finishes. Intermediate data is scaffolding: the
buffer you only created so you could erase it from something else. To
set or clear the flag, right-click a green output oval and toggle
Intermediate — ModelBuilder may have already flagged an
in-between output for you, so if you want to keep one, check
that the flag is off. Marking scaffolding intermediate keeps your
geodatabase from silting up with dozens of half-products every time
someone runs the tool.
Where should scaffolding live while it exists? ModelBuilder gives you
two built-in system variables for exactly this:
%scratchGDB% (a scratch file geodatabase the software
manages for you) and %scratchFolder% (a scratch folder for
non-geodatabase files). Point intermediate outputs there and you never
have to think about cleanup paths again. The percent signs are your
first glimpse of inline variable substitution, which gets its own
section shortly.
Models also honor geoprocessing environments — the ambient settings like output coordinate system, processing extent, and cell size covered in Chapter 22 (Geoprocessing in Depth). You can set environments at the model level (in the model's properties) so every tool inside inherits them, which is far more reliable than setting them tool by tool.
A model with everything hard-wired — this specific parcels layer, this specific buffer distance — is a macro: useful to you, today, once. A model becomes a genuine tool when you expose some of its variables as parameters: the blanks a user fills in on the tool dialog before running.
Making a parameter takes one gesture: right-click any variable oval
and choose Parameter. A small letter P
appears beside the element, and from now on that variable shows up as an
input box when anyone opens the model from the toolbox. Typical
candidates:
Not every variable in a model starts life visible on the canvas. Most
tool parameters are hidden inside the tool's dialog. To expose one as
its own oval — a prerequisite for making it a parameter — right-click
the tool, point to Create Variable > From Parameter, and
pick the parameter you want. It pops out as a value variable you can
rename, pre-fill with a default, and mark with the P.
Order matters too. The sequence in which you mark parameters becomes the order of the input boxes on the dialog; you can rearrange them (and set which are required versus optional) in the model's properties under the parameters section. Put the input data first, options in the middle, output last — the convention every Esri tool follows and every user expects.
Watch out: When you expose an output as a parameter, give it a sensible default path but expect users to change it. And test your model with inputs stored somewhere other than your own project — hard-coded paths hiding inside tool dialogs are the number one reason a model that "works on my machine" fails on a colleague's.
Inline variable substitution is the small feature that unlocks most of ModelBuilder's advanced behavior. Anywhere a tool accepts text — an output path, a where clause (the SQL filter expression selection tools use), a field calculation — you can embed the value of any variable in the model by wrapping the variable's name in percent signs.
Suppose your model has a value variable named County (a
parameter the user types in). You can set a tool's output to:
C:\Results\Analysis.gdb\Parcels_%County%At run time, if the user typed Marion, the output
becomes Parcels_Marion. The substitution happens as plain
text replacement just before each tool runs, which means it works in
where clauses too: a Select tool expression of
NAME = '%County%' selects the county the user named. (Note
the single quotes — substitution inserts the raw text, so you must
supply whatever quoting the expression syntax requires around it.)
Two details save headaches. First, the variable name inside the percent signs must match the element's name on the canvas exactly — another reason to rename your variables to short, meaningful words. Second, substitution is what makes iterators genuinely powerful, because every iterator produces variables (like the name of the current file) that you will almost always want to weave into output names. Which brings us to iterators.
An iterator is a special element that runs the rest of the model repeatedly — once for every item in some collection. It is ModelBuilder's version of a loop, and it is the feature that separates "I automated a workflow" from "I automated a hundred workflows."
You add an iterator from the Iterators menu on the
ModelBuilder ribbon. It appears on the canvas as its own distinctively
shaped element, with outputs you wire into the rest of the model just
like any tool's outputs. Each pass through the loop, those outputs hold
the current item.
The iterators fall into a few natural families:
| Family | Iterators (representative) | Loops over |
|---|---|---|
| Data on disk | Iterate Feature Classes, Iterate Rasters, Iterate Tables, Iterate Files, Iterate Datasets, Iterate Workspaces | Every dataset or file of a type in a folder or geodatabase |
| Rows and features | Iterate Row Selection, Iterate Feature Selection | Every row (or group of rows sharing a field value) in a table or layer |
| Values | Iterate Field Values, Iterate Multivalue | Every distinct value in a field, or every entry in a list the user supplies |
| Generic loops | For, While | A number range with a step, or "keep going until a condition changes" |
Two examples make the pattern concrete.
Batch processing files. You have a folder of
shapefiles delivered by a contractor and you want each one projected and
copied into your geodatabase. Add Iterate Feature Classes,
point it at the folder, and wire its output into a Project tool. The
iterator also emits a Name variable holding the current
dataset's name — so the Project tool's output can be
%scratchGDB%\%Name%_projected, and each shapefile lands
under its own name. Run once; the model loops through the whole
folder.
Per-category analysis. You want a separate summary
for each land-use category in a parcels layer.
Iterate Feature Selection, grouped on the land-use field,
selects each category's features in turn and emits the current
category's value as a variable — which you can substitute into output
names and expressions exactly as above.
One structural rule governs everything: a model can contain only one iterator, and once an iterator is present, every tool in the model runs on every pass — not just the tools wired downstream of it. There is no way to mark part of a model as "outside the loop," and no way to add a second loop alongside the first. When you need a step to run only once, or genuinely need loops within loops — for each workspace, process each feature class — the answer is the next section's technique: split the work across models and nest them.
One more companion deserves mention here: Collect
Values, found under the Utilities menu. An
iterator's outputs normally get overwritten on every pass; Collect
Values catches them all into a single multivalue list instead. It is how
you gather a hundred per-pass outputs so a downstream Merge tool can
combine them into one final dataset after the loop finishes.
Tip: Before wiring an iterator into a long chain, run the iterator with a single trivial tool attached (Copy Features works well) and watch what it produces. Understanding exactly what the iterator emits — the dataset, the name, the value — before building on top of it will save you an afternoon.
ModelBuilder normally figures out execution order from the data connections: a tool runs when its inputs are ready. Independent branches — two chains with no shared data — have no guaranteed order at all. Usually that's fine. Sometimes it isn't: you need the "delete old results" step to finish before the "write new results" step begins, even though no dataset flows between them.
A precondition is an explicit ordering constraint.
You draw a connector from any variable to a tool and choose
Precondition from the connection menu (or set it through
the tool's right-click properties). The connector renders as a dashed
line, visually distinct from solid data connections, and it means:
this tool may not run until this variable exists and, if it's a
true/false value, until it is true.
The two idioms you'll use constantly:
Watch out: A tool with a false precondition doesn't fail; it silently does nothing, and so does everything after it. If a model "ran successfully" but half your outputs are missing, check the preconditions before you check anything else.
Because a saved model is a tool, you can drag one model from the Catalog pane onto another model's canvas, where it appears as an ordinary rectangle. Its parameters become connectable inputs and outputs like any other tool's. This nesting — usually called a submodel — is how you solve two recurring problems.
The first is the one-iterator limit. Build the inner loop as its own model (say, "Process one workspace," containing an Iterate Feature Classes), then place it inside an outer model whose iterator walks workspaces. Each pass of the outer loop invokes the entire inner model, inner loop and all. Nested iteration, achieved by composition. The same trick handles run-once steps: keep them in an outer model, and put the iterator in a submodel it calls.
The second is plain reuse. If five of your models all begin with the same three cleanup steps, extract those steps into a "Prep Input" model with an input parameter and an output parameter, and drop it into all five. Fix a bug in the prep logic once and every consumer inherits the fix. This is the same don't-repeat-yourself instinct that drives good schema design (see Chapter 12) applied to workflows.
Keep submodels small and single-purpose, name them as verbs ("Clip And Project," "Score One County"), and give them clean parameter interfaces. A well-factored family of models reads like a set of sentences; a single 40-tool mega-model reads like a ransom note.
The Utilities menu on the ModelBuilder ribbon (recent
versions group the conditional ones under a Logical heading
nearby) holds small model-only tools that don't process geography at all
— they manipulate values, paths, and control flow. Four of them do most
of the work.
Calculate Value is the most important utility in
ModelBuilder, full stop. It evaluates a Python expression and returns
the result as a variable. Need a date-stamped output name? A buffer
distance computed as ten percent of a parcel's average width? Today's
date formatted for a filename? A true/false answer to feed a
precondition? Calculate Value does all of it. It has three parts: the
expression itself, an optional code block where you can define a small
Python function the expression calls, and a data type setting that tells
ModelBuilder what kind of value comes out (get the data type right, or
downstream tools will refuse the connection). Inline substitution works
inside the expression, so %County% and friends are
available. It is, quietly, your first line of Python — a single
expression at a time, inside the comfort of the canvas.
Get Field Value reads one value from the first row of a table — typically after a selection has narrowed the table to the row you care about — and hands it to you as a variable. It's the standard way to pull a number or name out of your data and into the model's logic.
Parse Path takes a dataset and splits its path into pieces — the file name, the containing folder or geodatabase, the extension — each usable inline. Indispensable inside iterators when you need "the name of the current thing" in a form suitable for building output names.
The If tools and Merge Branch give you true branching. Recent versions of Pro ship a family of logical tools — If Data Exists, If Field Exists, If Selection Exists, If Value Is, and relatives — each of which outputs a pair of true/false variables you wire as preconditions on alternative branches. One branch runs, the other silently doesn't. Then Merge Branch brings the alternatives back together: it accepts several possible inputs and passes along whichever one was actually created, so the rest of the model doesn't care which branch ran. There is also a Stop utility that ends a While loop's iteration when a condition flips — the standard way to build "keep processing until nothing is left" models.
None of these tools exist outside ModelBuilder; you won't find them in the regular geoprocessing search. They are the connective tissue that turns a straight pipeline into a workflow with judgment.
A model you built last year is a stranger's model. Documentation is what makes it usable anyway, and ModelBuilder gives you three layers of it.
On the canvas: rename every element to say what it is in the workflow's terms ("Wetland buffer, 100 m" beats "Buffer_Output_4"), and add labels — free-floating text you can place anywhere via right-click — to annotate why a section exists or what a tricky precondition is doing. Group related sections visually with Auto Layout and spacing. The canvas should read as its own flowchart-style documentation.
In the tool metadata: right-click the model in the
Catalog pane and choose Edit Metadata (the exact wording
shifts between versions, but it lives on the item's right-click menu).
Here you write the summary that appears in search results, the usage
notes, and — most valuably — a description for each parameter.
Those parameter descriptions surface as the help text users see beside
every input box when they open your tool. Five minutes of parameter
documentation converts a mystery dialog into a self-explaining one.
Through validation: before you call a model
finished, click Validate and confirm every element fills
with color — hollow elements mean something is unset. Then test it the
way users will actually run it: from the toolbox dialog, with fresh
inputs, on a machine or folder structure that isn't yours if you can
manage it. Check that intermediate data really gets cleaned up, that
outputs land where the dialog said they would, and that a second run
doesn't fail because the first run's outputs already exist (enabling the
geoprocessing option that lets tools overwrite existing outputs is the
usual fix; see Chapter 22).
Tip: Adopt a naming convention for the models themselves and stick to it — verb-first labels ("Summarize Parcels By Flood Zone"), a versioned toolbox for anything shared, and a scratch toolbox for experiments. Toolbox hygiene is cheap when the toolbox holds three models and painful when it holds thirty.
Sharing a model means sharing its toolbox. The simplest path is also
the most common: copy the toolbox file to a shared network location, or
hand it to a colleague, and they add it to their project via the Catalog
pane (right-click Toolboxes > Add Toolbox). Everything
in this chapter — the dialog, the parameter help, the intermediate-data
cleanup — comes along for free.
Three portability rules keep shared models from breaking:
%scratchGDB%. If the model needs supporting data that never
changes (a boundaries layer, a lookup table), either parameterize it or
store it in a folder that travels with the toolbox as one bundle — and
check the tool's properties for an option to store relative rather than
absolute paths, so the reference survives the move.Beyond simple file sharing, two bigger distribution channels exist. You can package a model with sample data into a geoprocessing package (a single portable file bundling the tool and its data) and share it through your ArcGIS Online organization, which is convenient for tutorials and handoffs. And a model can be published as a web tool — a geoprocessing service that runs on a server and can be invoked from web apps and scripts rather than from Pro. That has traditionally been an ArcGIS Enterprise capability, though recent ArcGIS Online releases support web tools as well; either path involves server-side considerations beyond this chapter. See Chapter 32 (REST Services and Integration) and Chapter 35 (ArcGIS Enterprise and When You Need It).
ModelBuilder and Python (Chapter 31) drive the same geoprocessing engine — every tool on your canvas has a one-line Python equivalent. The question is never which is more powerful at running tools (they're equal) but which is the better medium for the logic around the tools. Honest signals that you've outgrown the canvas:
| Situation | Stay in ModelBuilder | Move to Python |
|---|---|---|
| Linear chains, batch loops, simple branching | Yes — this is the sweet spot | Overkill |
| Error handling ("if this tool fails, log it and continue") | Effectively impossible | Natural (try/except) |
| Row-by-row data manipulation and edits | Clumsy (Get Field Value one value at a time) | Natural (cursors — arcpy's row-by-row readers and writers) |
| Scheduled, unattended runs (nightly jobs) | Awkward | Standard practice |
| Talking to anything outside ArcGIS (files, APIs, email) | Not really possible | Trivial |
| Nested loops three levels deep, dozens of Calculate Values | A ransom note | Readable code |
| Colleagues who need to review or version-control the logic | Diagrams diff poorly | Text diffs cleanly |
The practical rule of thumb: when you notice you are fighting the canvas — stacking Calculate Values to fake real logic, nesting submodels just to get loops, or wishing a failed tool could be caught instead of halting everything — the canvas is telling you something.
The graduation path is gentler than it sounds. First, ModelBuilder
can export a model to a Python file (Export, on the
ModelBuilder ribbon). Treat the result as a first draft, not a finished
script: straightforward tool chains export cleanly, but iterators and
some model-only constructs do not translate well, and the generated code
is verbose. Its real value is showing you exactly what your model looks
like as code, tool names and parameters spelled out, so you're never
starting from a blank page. Second, you don't have to choose sides: a
Python script can be wrapped as a script tool and dropped into
a model as one of its boxes, and a model can be called from
Python like any other tool. Many mature workflows are hybrids — a model
providing the friendly dialog and overall shape, with one script tool
inside doing the part the canvas couldn't express.
Watch out: Don't let "we should really rewrite this in Python someday" stop you from building the model today. A working model this afternoon beats a hypothetical script next quarter — and because the model documents the workflow visually, it makes the eventual rewrite easier, not harder.
ModelBuilder rewards a specific habit of mind: noticing repetition. Every time you catch yourself running the same three tools in the same order, that's a model asking to be built. Build it small, test it tool by tool, expose the right parameters, write the parameter help, and put it in a shared toolbox. You'll know it worked the first time a colleague runs your workflow correctly without asking you a single question — and the first time you run it, six months later, without having to remember anything at all. For a full worked example that folds a model into a larger project, see Chapter 36 (Worked Project: From Raw Data to Published Dashboard).