Power BI Developer Job Description Template 2026

Last updated: October 13, 2026

By Robert Ardell, Co-Founder and Strategic Advisor, KORE1

A Power BI developer job description should state the storage mode and model size, the license and capacity it runs on, how much Power Query and DAX the role owns, how content reaches production, and a published pay range. Generic BI postings skip all five. The candidates who know Power BI notice.

She called me on her fourth day.

We had placed her with an agricultural equipment distributor in Loveland, Colorado, about 600 people, eleven dealer locations, a finance team that lived in Excel, and an operations team that had been promised Power BI for two years. The posting asked for “advanced DAX, Power Query, and Power BI Service experience.” She had all three. Plenty of it. Six years, the last two on a Fabric F64 capacity at a medical device company in Boulder.

Day four, she opened the admin portal. Every author was on a Pro license. Every one. The sales semantic model sat at 940 MB against a 1 GB ceiling. Its refresh ran an hour and fifty-two minutes against a two-hour limit and used all eight of its daily scheduled slots. And the VP of operations wanted dealer inventory updated hourly by the end of the quarter.

Nobody had lied to her. Nobody had thought to say it either.

She stayed, and she’s good, and her first real deliverable turned out to be a capacity business case instead of a dashboard. Fine. But she would have asked very different questions in the interview, and two of the four finalists before her would have self-selected out, if the posting had carried one sentence about the license and one about the model.

I helped start KORE1 in 2005, and our Power BI developer staffing desk gets paid when a company hires through us, so weigh the advice with that in mind. If you haven’t settled which parts of the data stack this hire is responsible for, start with the BI developer job description template I wrote in September. This one assumes the platform is already Power BI and the posting should read like it.

Seven Lines a Power BI Posting Needs That a BI Posting Doesn’t

A Power BI developer job description is a BI posting with the platform’s own constraints written in. Microsoft publishes those constraints, from model size caps to refresh quotas to which license unlocks which feature. Candidates with real Power BI years read a posting looking for them. Those limits decide what their week looks like. All of it.

• Storage mode. Import, DirectQuery, Direct Lake, or a composite, plus the size of the biggest model and the row count of its largest fact table.
• The license and capacity. Pro, Premium Per User, or a Fabric F SKU, and which one the developer’s own workspace sits on.
• Whether the Power Query work folds back to the source, and whether incremental refresh is already configured or is the job.
• How many measures the main model carries. Give the number. “About 380 measures, 14 calculation items” tells a senior candidate more than any adjective.
• How a change gets to production, from Git and deployment pipelines down to “someone publishes from Desktop on Friday afternoon.” Both are real answers.
• Who reads the reports, employees inside the tenant or customers inside your product.
• The pay range, which several states now require and Colorado has fined companies over.

The four profiles that all get called Power BI developer are covered in our hiring guide, along with how to screen DAX. Everything below is about the posting. For the interview that follows, our interview loop for a Power BI developer picks up where the posting leaves off.

Import, DirectQuery, or Direct Lake? Name the Storage Mode

Storage mode decides where a Power BI developer spends the week. It’s a table property, so one model can mix them. Most lean hard one way. Pick the dominant mode and name it.

Direct Lake is the one that changes the hire most. Microsoft’s Direct Lake documentation describes it as reading Delta tables in OneLake straight into memory, with a “refresh” that copies only metadata and takes seconds. It requires a Fabric capacity. No gateway. None. And the flavor called Direct Lake on SQL falls back to DirectQuery whenever a table is really a SQL view. A developer who has spent three years tuning Import refreshes in Power BI Desktop and a developer who has spent the last year arguing about V-Order and Parquet file counts are not interchangeable, even though both will list “Power BI” first on the resume.

Size goes in too. Numbers. Not adjectives. “Large datasets” means 50 MB to one candidate and 50 GB to another. On a Fabric F2 through F8, Microsoft’s guardrail for a Direct Lake table is 300 million rows; on an F64 it’s 1.5 billion. If your biggest model is nowhere near either, say that. It’s fine to be small. It isn’t fine to make a senior candidate find out in week one.

The License Line Most Postings Leave Out

This one costs the most interviews.

Power BI features are gated by license. The gates are specific. A developer on Pro and a developer on a Fabric capacity have different tools, so a candidate deciding whether your job is a step forward or a step back needs to know which one you bought.

Every row comes from Microsoft’s own pages, namely the Power BI pricing page, the data refresh documentation (eight refreshes a day on shared capacity, 48 on Premium, PPU, or Fabric, and a two-hour refresh limit on shared capacity against five on Premium), the large semantic model page, and the Copilot requirements, which say plainly that a Pro or PPU license alone isn’t enough.

Read the Loveland numbers against that table and the problem explains itself. A 940 MB model on Pro, eight refreshes already spoken for, a two-hour ceiling with eight minutes of slack. No amount of DAX skill turns that into hourly inventory. None. A license change does, or an incremental refresh policy, or both, and the person you hire will spend their first month proving which.

So put one line in the posting. “Authors are on Pro today; we expect to move to an F64 in the second half of 2027, and you’ll help size it.” That sentence is honest, it filters, and it’s the kind of project strong candidates want. The ones who only want a finished Fabric shop will pass. Good.

Say Whether the Power Query Folds

Most postings give Power Query one bullet. “Experience with Power Query.” Which part? The ribbon, the M language, Dataflow Gen2, the gateway it runs through?

Query folding is the part a senior hire cares about. When a step folds, Power BI hands it to the source as SQL, so SQL Server filters 60 million rows down to yesterday’s 40,000 and ships only those. When it doesn’t, Power BI asks for all 60 million and filters them on its own side. Same report. Same visuals. Very different Tuesday.

Incremental refresh lives or dies on it. Microsoft’s incremental refresh guide says the policy filters on two reserved, case-sensitive parameters, RangeStart and RangeEnd, and that when the filter doesn’t fold in a pure Import policy the engine may retrieve every row and run the service or the on-premises data gateway out of resources, “effectively defeating the purpose of incremental refresh.”

A credit union in Grand Rapids learned this on a 60-million-row transactions table sitting in Oracle. Somebody had added a merge step to look up branch names before the date filter. Folding stopped. Right there. Refresh climbed from 11 minutes to just under two hours over about eight months as the table grew, and nobody connected the two, because the report still loaded.

The developer they eventually hired found it in an afternoon with Power Query Diagnostics.

What to write, then, depends on which job you have.

If the transforms live in the model, say so, and name the sources. “Power Query against SQL Server, Oracle 19c, and about thirty SharePoint lists.” SharePoint lists don’t fold. A good candidate will see that line and already know where the trouble is. If the transforms live upstream in Dataflow Gen2, a Fabric pipeline, or dbt, say that, and say the developer is expected to push logic upstream rather than bury it in M. And if incremental refresh isn’t set up yet on a table that badly needs it, that’s not a footnote. That’s the first project. Name the table.

Then DAX. Skip “advanced.” Give the count and the hardest thing in it. “About 380 measures, a calculation group for time intelligence, and a currency conversion measure that three people have tried to fix” is a posting a DAX person reads twice.

How Does a Change Reach Production?

Two Power BI shops can use identical features and work in completely different ways, and the difference is almost always deployment.

At one end, a developer opens a .pbix file on a laptop, edits it, and publishes straight to the workspace everyone reads from. There’s one copy. Just one. Version history is a folder named “old.” At the other, the same report and semantic model are saved as a Power BI Project (PBIP), which Microsoft describes as folders of plain text files built for Git, the model itself written in TMDL, changes committed to Azure DevOps or GitHub through Fabric Git integration, reviewed in a pull request, and promoted dev to test to prod through deployment pipelines.

Most companies sit somewhere in between. That’s fine. Normal, even.

The posting has to say where, for two reasons. A developer who has worked in the second world will not go back to the first without a plan to leave it, and you should know that before the offer. And a developer who has only worked in the first world can’t run the second on day one, however good the DAX. Neither is a skill gap you can see on a resume. Tabular Editor, ALM Toolkit, PBIP, and TMDL show up as keywords on plenty of resumes from people who used them once.

Write the honest version. “Today we publish from Power BI Desktop. This year we’re moving to PBIP in Azure DevOps with three-stage deployment pipelines, and you’ll set it up.” Or “Our models live in GitHub as TMDL; every change goes through a pull request reviewed by one other developer.” One of those attracts a builder and the other attracts someone who wants guardrails already in place. Both are good hires for the right shop. One caution if you still run on-premises. Microsoft notes PBIP isn’t supported in the Power BI Desktop build for Report Server, so don’t promise Git workflows to a Report Server team without checking.

Internal Reports or Embedded in Your Product?

Short section. Big difference.

A Power BI developer building reports for employees inside your Microsoft 365 tenant and a Power BI developer embedding reports in a software product your customers log into are doing different jobs. The embedded version means a service principal instead of user sign-in, embed tokens generated by your application, row-level security that keys off a customer ID rather than an employee’s email, the JavaScript client library on the front end, and a capacity sized for your customers’ traffic rather than your employees’.

A logistics software company in Kalamazoo posted for a “Power BI Developer” last year and interviewed seven internal-reporting candidates before anyone noticed none of them had touched the REST API. The eighth had built embedded analytics for a property management platform. She got the job and the req stopped being a puzzle.

If the reports are for customers, put “embedded” in the title.

Pay, and What Colorado Makes You Print

Our Power BI desk’s own placement data puts mid-level base salaries at $95K to $135K and senior at $140K to $185K, with contract bill rates between $80 and $135 per hour for mid-level work. Fabric capacity administration and embedded work both push a candidate toward the top of those bands. Before you settle on a number, put your actual scope into our free salary benchmark assistant and see where it lands.

Then print it.

Colorado’s Equal Pay for Equal Work Act is the law I’d write to if your company has anyone there, and it reaches further than most pay-range rules. The Colorado Department of Labor and Employment summarizes it this way. Compensation must appear in all job postings and notices, internal and public, along with information about benefits and how and when to apply. Employers also have to tell employees about job openings and then tell them who was selected. And a separate part of the law bars asking applicants about their pay history at all.

Enforcement is real. Ask DaVita. As of the state’s table updated October 7, 2026, the division had taken 3,049 pay transparency complaints since January 1, 2021, issued 24 citations, and assessed $841,500 in fines. The largest was DaVita’s $552,000, cited in January 2025 and settled down to $298,000. Real money. For a missing sentence.

For a Power BI posting, the Colorado-proof version is three lines. A base range. A plain description of benefits and any bonus. A date the posting closes. If you’re hiring along the Front Range, our IT staffing desk in Denver writes those three lines into every Colorado req it touches.

Power BI Developer Job Description Template

Replace everything in brackets. The notes in brackets explain why the line is there; delete them before you post.

Job Title

[Power BI Developer / Senior Power BI Developer / Power BI Developer, Embedded Analytics] [Keep “Power BI” in the title. Candidates search the product name. If the job is mostly Fabric engineering, say “Power BI and Fabric Developer” instead of hoping a recruiter reads the body.]

About the Role

[Company] wants a Power BI developer to own [the finance and operations semantic models / customer-facing embedded reports] for [who reads them, by function or by customer type]. You’ll report to [role] and work most days with [names of the teams whose numbers you’ll publish].

The Model You’ll Inherit

[Our largest model is a [2.3 GB] [Import / DirectQuery / Direct Lake / composite] model with [140 million] rows in its main fact table and about [380] measures. It refreshes [six] times a day from [SQL Server / Snowflake / a Fabric lakehouse].] [If incremental refresh isn’t configured on a table that needs it, name the table here. It’s the first project.]

Licensing and Capacity

[Authors are on [Pro / Premium Per User], and content lives on [shared capacity / a Fabric F[64] capacity].] [If a move is planned, give the quarter and say whether this hire sizes it.] [Say who administers the tenant and the gateway. If it’s this person, give a rough share of the week.]

What You’ll Own

• The semantic model, start to finish. Relationships, measures, calculation groups, row-level security, and the descriptions that let the next developer, or Copilot, understand it.
• Refresh. Scheduling, failures at 5 a.m., incremental refresh policies, and the conversation when a source changes without warning.
• [Power Query against [list the actual sources], with transforms folded back to the source wherever the source allows it.]
• Report performance, measured with Performance Analyzer and DAX Studio rather than guessed at.
• [Embedded only: embed tokens, service principal permissions, and per-customer row-level security inside [product name].]

How Work Ships Here

[We publish from Power BI Desktop today / Our reports and models are saved as PBIP in [Azure DevOps / GitHub], and changes go through [pull request review and a three-stage deployment pipeline].] [If you want the hire to build this, say so.]

What You Bring

• [3+ / 6+] years building Power BI semantic models that other people relied on, in production, with real refresh schedules.
• DAX you can explain out loud. Filter context, context transition, and why a total row doesn’t equal the sum of the rows above it.
• Power Query beyond the ribbon, including knowing when a step breaks folding and how to check.
• SQL good enough to read what DirectQuery sends to the source and tell the warehouse team what to index.
• [A story about a number two departments disagreed on, and how it got settled.]

Nice to Have

[Fabric: lakehouses, Dataflow Gen2, Direct Lake.] [Tabular Editor and the XMLA endpoint.] [Paginated reports, if you still run them.] [Your industry. Ag equipment dealers, credit unions, and SaaS billing each carry their own model traps.] [PL-300 or DP-600, listed here and not under requirements.]

Pay, Benefits, and How to Apply

[$95,000 to $135,000] base [for this level], plus [bonus target and how it’s measured]. Benefits include [medical, dental, vision, 401(k) match, PTO days]. [Work arrangement: on site, hybrid with the office days named, or remote with the eligible states listed.] Applications close [date]; apply at [link]. [Colorado requires all of this in internal postings too, and requires telling employees who got the job.]

Questions From the Analytics Manager’s First Draft

Our model is 3 GB and we’re on Pro. Is that a hiring problem or a licensing problem?

Licensing, first. Pro caps a semantic model at 1 GB, so a 3 GB model can’t live in a Pro workspace no matter who you hire. The fix is Premium Per User, a Fabric capacity, or a much smaller model, and a good candidate will ask which one you’ve budgeted.

Put the decision in the posting if it’s made. If it isn’t, say the hire will help make it. That sentence attracts people who’ve done a Pro-to-capacity move before.

Do we mention Fabric if we’re not on it yet?

Only with a date. “Fabric experience a plus” with no plan behind it tells strong candidates you’re collecting keywords, and the ones who want Fabric work will ask about the timeline in the first call anyway.

“We expect to move to an F64 in Q3 2027” is a plan. “Exposure to Microsoft Fabric” is a wish. Candidates can tell them apart, and so can we, about three minutes into the intake call.

Can one person own the gateway, the capacity, and the reports?

At a few hundred users, yes, if you say so in writing and price it. Administration is real work, and it’s the part of the job that grows quietly until it eats the reporting backlog.

We treat Power BI admin as its own role, with its own band, for a reason. If admin is more than about a fifth of the week, write it into the posting and the range. If it’s less, name who covers it when your developer is on vacation and the on-premises gateway stops answering at 5 a.m. on the first business day of the month. It will.

Does Copilot change what we should ask for?

A little, and only on a paid capacity. Copilot in Power BI needs a Fabric F2 or larger capacity, or Premium P1 and above, and Microsoft says a model that hasn’t been prepared for AI can return generic or inaccurate answers.

That preparation is new work. Clear measure names, descriptions on tables and columns, synonyms, hiding helper columns nobody should query. If Copilot is on your roadmap, add one line under responsibilities saying the developer keeps the model readable for it. If you’re on Pro, leave Copilot out of the posting entirely, because the hire can’t use it.

What if we don’t know half of these answers?

Twenty minutes with whoever administers your Power BI tenant will get most of them. License types, capacity, model sizes, refresh history, and gateway status are all in the admin portal and the semantic model settings.

The measure count takes longer. Not much. Open the model in Tabular Editor or DAX Studio and it’s right there. Asking these questions before you post also tends to surface the real job, which is the point.

Our reports run on an on-premises Report Server. How much of this applies?

About half. Storage mode, model size, query folding, and DAX all apply to Power BI Report Server, while Fabric capacity, Direct Lake, and Copilot are cloud features a Report Server team won’t touch.

Say so near the top of the posting. A developer who has spent five years in the Power BI service will otherwise assume that’s where the job lives, and find out in the second interview. Source control looks different too, because Microsoft’s PBIP project format isn’t supported in the Report Server build of Power BI Desktop. If a move to the service is planned, give the year. If it isn’t, that’s fine. Some very good developers prefer the on-premises world and will tell you so.

The Tenant Already Knows

Everything a strong Power BI candidate wants to know about your job is already written down somewhere inside your tenant. The license on every author. The size of every model. The refresh history. How many measures. Whether anything is in Git. The posting just has to copy it out.

That’s the template. Really. Six lines from the admin portal, a pay range, and a closing date.

Some numbers from our side of the table. IT searches at KORE1 close in 17 days on average. Twelve months after a direct hire start, 92% of those people are still employed there. Our recruiters carry 15+ years of experience apiece and work 30+ metros, and none of those numbers come from sourcing harder than the next firm. Most of the difference is made before a single resume shows up, in the posting. If you’d like someone to read a Power BI req before it goes live, send the draft to a recruiter, whether you end up running a direct hire search, bringing in contract Power BI developers for a capacity move, or doing it yourself. Our Power BI recruiting desk will tell you which of the seven lines is missing.