Preparing data: field types, aliases, domains and date fields

The dashboard that lied. Picture a Monday morning in a city operations center. The water main break dashboard says three breaks happened today, but the field crews know there were eleven. The map is fine. The dashboard software is fine. The problem sits one layer down, in the data. Someone stored the break date as plain text, so the "today" filter can't read it. The status chart shows bars labelled 1, 2 and 3, and nobody in the room remembers what those numbers mean. A dashboard can only be as trustworthy as the fields behind it. In this lesson we fix that at the source, before anyone builds a single chart.

What you will learn. By the end of this lesson you'll be able to do three things. First, pick the right field type for each attribute in a hosted feature layer, so numbers behave like numbers and dates behave like dates. Second, use aliases and domains, which give your fields and values friendly, consistent names that a manager can read at a glance. Third, set up date fields so that time filters, like "the last twenty four hours", and trend charts work the way you expect. We'll use a water main break layer as our running example throughout.

Field types decide what a dashboard can do. Every field in a hosted feature layer has a type, which is simply the kind of value it's allowed to hold. A string field holds text, like a street name or a crew note. An integer holds whole numbers, like a pipe diameter in inches. A double holds numbers with decimals, like gallons lost. A date field holds an actual moment in time. Think of field types like labelled bins in a warehouse: if you put bolts in the paint bin, the inventory count goes wrong. Dashboards read these types. An indicator can sum or average only numeric fields, and time filters work only on date fields.

Worked example: numbers stored as text. What happens when pipe diameters arrive as text? This small example builds three water mains with diameters of twelve, eight and twenty four inches, stored as strings. When we sort the text, eight lands last, because text sorts character by character, and the character one comes before eight. That's exactly how a dashboard list or chart would order them. Then we convert the column to integers and sort again. Now it reads eight, twelve, twenty four, and the maximum is correctly twenty four. The same thing happens in ArcGIS Online, so check your types before you publish.

Aliases: friendly names for fields. Field names are often written for databases, not people. You'll see things like ASSET underscore ID, STAT underscore CD, or BRK underscore DT. An alias is a display name you set on the field, such as Main ID, Status, or Break date. Dashboards, pop-ups and tables show the alias, so your executives never have to decode abbreviations. A handy detail: you can change an alias at any time in the layer's Data tab, and nothing breaks, because the underlying field name stays the same. Set aliases once on the layer and every new map and dashboard built on it starts with them.

Domains: one list of allowed values. A domain is a rule about which values a field may hold. The most common kind is a coded value domain, which is a pick list. The layer stores a short code, like one, two or three, and shows a description, like Reported, Crew dispatched or Repaired. A range domain instead sets a minimum and maximum, for example pipe diameters between two and forty eight inches. Domains matter hugely for dashboards. Without them, field crews type "repaird" or add a trailing space, and your status chart suddenly has five bars instead of three. With a domain, every category lines up.

Date fields and time zones. Now the field that caused our Monday morning problem. A date field stores a real moment in time, so a dashboard can ask questions like "breaks in the last twenty four hours" or draw a serial chart, which is a chart of values over time, such as breaks per day. ArcGIS Online stores dates in UTC, which stands for Coordinated Universal Time. Think of it as one shared world clock, the way airlines schedule flights across time zones. When someone views the dashboard, dates are shown in their own local time. So if a break is logged at three in the afternoon in Chicago, the stored value is later in the day in UTC, and that's correct.

A data prep routine. Here's a routine you can apply to any layer, whether it's water main breaks, 311 service requests, or storm damage reports. Start by reviewing every field in the Data tab, and delete or hide the ones nobody needs. Fix types first, because types are the hardest thing to change later. Then set aliases so names read clearly. Next add domains to any field with a fixed set of categories, like status, priority or asset type. Check your date fields hold real dates. Finally, open the layer in a web map and confirm pop-ups and filters behave.

Worked example: counting breaks by status. Let's see what a dashboard does behind the scenes. On the left are six water main breaks, each storing only a status code. On the right is the coded value domain. A category chart's work can be written as a query. Each break's code is matched to its description, so one becomes Reported and two becomes Crew dispatched. Then the rows collapse into groups, one per status, with a count. Sorting puts the busiest status first. And here are the final counts: three reported, two dispatched, one repaired. Clean labels, no typos, and the numbers add up to six.

Common mistake: fixing types too late. Here's the trap that catches almost every team once. You publish a layer, build the web map, build the dashboard, and then notice the break date is a string. In ArcGIS Online you can't simply change a field's type. You have to add a new date field, calculate values into it, and then repoint every pop-up, filter, indicator and chart that used the old one. On a busy operations dashboard that's an afternoon of rework. The fix is cheap if you do it early: check types in your spreadsheet or source data before you publish.

Recap. Let's pull it together. Field types decide what a dashboard can do: numbers can be summed and averaged, dates can be filtered by time, and text can be grouped and counted, but not summed or filtered by time. Aliases give fields names people understand, and domains keep category values consistent, so charts show three clean bars instead of five messy ones. And a real date field, stored in UTC and shown in local time, is what makes "last twenty four hours" filters and daily trend charts work. Get these right on the layer, and every map and dashboard built on it benefits.

Your exercise. Before the next lesson, try this on real data. Open a hosted feature layer you own, such as service requests or outages. If you don't have one, download a Living Atlas dataset, for example as a CSV or file geodatabase, and publish it as your own hosted feature layer, so you can edit its fields. Go to the Data tab and write down each field's name, type, alias and any domain. Then give three fields friendly aliases and create one coded value domain for a status or priority field. Finally, flag any text field that should really be a date or a number. Next time, we'll build the web map on top of this clean layer.