Blog

How to build governed data segments without waiting on IT

You need a list of all customers in the DACH region who attended an event last year but have not renewed their contract. You know the data exists. You just cannot get to it without filing a ticket and waiting for someone in IT to write the query.

So you do what everyone does. You export what you can to Excel, manually cross-reference two spreadsheets, and hope you picked the right fields. The campaign goes out. The numbers look close enough. Nobody is fully confident.

Key takeaways

  1. Business teams wait days or weeks for data segments because every request routes through IT, even for recurring lists.
  2. The Excel workaround creates ungoverned, inconsistent data: different people use different fields, filters, and definitions.
  3. Template-based segmentation lets IT define the right logic once so business users can build segments on their own, with guardrails.
  4. Governed self-service means independence for business teams without sacrificing accuracy, audit trails, or access controls.

The segmentation bottleneck

Marketing needs data segments constantly. Target lists for campaigns, attendee lists for events, exclusion lists for opt-outs, region-specific cohorts for localised messaging. These are not one-off requests. They repeat every week, every month, every quarter.

But the data lives across CRM tables, event systems, and subscription databases. Getting a segment that combines data from two or more of those sources means someone has to understand how the tables relate, which fields to use (and which five similar-sounding fields to ignore), and how filters should be applied. That someone is usually in IT.

IT is not slow on purpose. They have a backlog. Your segmentation request sits behind infrastructure work, security patches, and other data requests from Sales, Finance, and Operations. Turnaround is measured in days when you need it in hours.

Standard tools do not help much either. Dynamics 365 Marketing only segments on Accounts, Contacts, and Leads. Need to segment on event attendance, product usage, or contract status? That is outside the box. Power Apps does not offer real segmentation at all.

What goes wrong with Excel workarounds

When IT cannot deliver on time, business teams improvise. They export raw data to Excel, apply their own filters, and build segments manually. It works, technically. But it creates a set of problems that compound over time.

First, definitions drift. One marketer filters "active customers" by last login date. Another uses last purchase date. A third uses contract renewal status. All three believe their list is correct. The CEO sees three different numbers in three different reports and trusts none of them.

Second, there is no governance. Nobody tracks who exported what, when, or why. Sensitive fields (personal data, financial data) end up in spreadsheets on laptops. That is a compliance risk in any regulated environment, and in Europe it is a GDPR problem waiting to happen.

Third, the work is not reusable. Every time the same segment is needed, someone starts from scratch. The knowledge about which fields to use and how to combine them stays in one person's head. When that person leaves or is on holiday, the segment is gone.

How template-based segmentation works

The pattern that fixes this separates two jobs. IT (or a data-savvy power user) defines the segmentation logic once. Business users consume it whenever they need to, without touching the database.

The logic lives in data access templates. A template for "event attendees by region" knows which tables to query, how those tables relate to each other, which fields represent the region, and which filters to apply. The business user selects the template, picks their parameters (DACH, Q4 2025), and gets a result. No SQL. No guesswork about field names.

Templates can also handle multi-step logic. Need all contacts who match criteria A, minus everyone already contacted this quarter, plus a newsletter subscriber list? That is a combine-subtract-add operation. With templates, each step is a defined data operation. The business user assembles them like building blocks.

This is the approach dhino Fetch uses. IT builds the templates with the correct logic, relationships, and guardrails. Everyone else uses them. The domain knowledge does not live in someone's head anymore. It lives in the platform, available to anyone with permission.

What governed self-service looks like in practice

Self-service without governance is just a faster way to make mistakes. The reason IT controls data access is not bureaucracy. It is because giving raw database access to everyone creates real risk. The goal is not to remove IT from the picture. It is to change their role from "run this query for me" to "build the templates that everyone uses safely."

In a governed model, access controls follow the user. A marketing manager sees marketing-relevant data. A regional lead sees data for their region only. Field-level permissions keep sensitive columns out of exports. Every segment request is logged with who ran it, what parameters they used, and when. That is the audit trail that compliance teams need.

The result is deterministic. Same template, same parameters, same answer. Whether a junior marketer runs the segment on Monday or the head of marketing runs it on Friday, the logic is identical. No more conflicting numbers in leadership meetings.

IT builds once. Business uses many times. The backlog shrinks because recurring requests become self-service. New use cases get added as new templates, not as new tickets. For a detailed look at how this applies to marketing campaign segmentation, the scenario page walks through a complete example.