If you work with Power BI, you will come across file types like .pbix, .pbip, .pbit and .pbids. They look similar, but each one has a different job. Knowing which is which saves time, avoids confusion, and makes teamwork easier.
This guide covers what each file type does and when to use it. It starts with the files you work with directly, then opens up a .pbip project to show the files inside it.
|
# |
Extension |
What it is |
Best used for |
|
1 |
.pbix |
Everything in one packaged file |
Everyday building and sharing |
|
2 |
.pbip |
Project folder of readable files |
Git, teamwork, version control |
|
3 |
.pbit |
Report template without data |
Reusing a design for many clients |
|
4 |
.pbids |
Saved data connection |
Quick, consistent source setup |
|
5 |
.pbiviz |
Custom visual package |
Adding specialised charts |
|
6 |
.tmdl |
Model definition in plain text |
Reviewing and editing the model |
|
7 |
.pbir |
Report definition and link to the model |
Editing pages, visuals and filters |
|
8 |
.bim |
Older single-file model format |
Legacy projects and tools |
This is the standard Power BI file. The data, model, pages and visuals are all packed into a single file.
Best for: day-to-day report building, and sharing or publishing a complete report.
Limitation: it is a sealed file. It is hard to see exactly what changed between two versions, and only Power BI Desktop fully understands it.
A Power BI Project (PBIP) saves the same report as a folder of simple, readable text files instead of one sealed file. A small .pbip file opens the project, and the folders keep the model and the report separate.
Best for: version control with Git, team collaboration, and reviewing changes.

A template keeps the design and logic but removes the data. When someone opens it, Power BI asks for connection details or parameters and loads the data fresh.
Best for: reusing one report design across many clients, teams or tenants, and starting new reports from a proven structure.
This small file stores only how to connect to a data source, such as the server and database name. It contains no data and no report.
Best for: giving colleagues a ready-made connection. Opening the file launches Power BI with the source already selected.
A .pbiviz file is a package for a custom visual, such as a chart type that Power BI does not include by default. Once imported, it appears alongside the built-in visuals.
Best for: adding specialised visuals to your reports, or sharing a visual your team has built.
When you save a report as a PBIP, Power BI creates one small .pbip file and two folders: one for the semantic model and one for the report. These folders contain several more file types, and each can be opened and edited on its own.

TMDL (Tabular Model Definition Language) describes the semantic model, including tables, columns, measures and relationships, as readable text. It holds the structure, not the rows of data.
Best for: reviewing model changes line by line, and creating or updating measures and tables.
The .pbir file links the report to its semantic model. The report's pages, visuals and filters are stored alongside it in the PBIR format, as a folder of small files rather than one large block.
Best for: editing pages and visuals as files, tracing which filters affect which visual, and applying changes consistently.
BIM stores the entire model in a single JSON file. It was the standard before TMDL. New projects now favour TMDL, because a single large file is harder to read and to compare between versions.
Best for: older projects and external tools that still use it.
Building a report on your own: use .pbix. It is the simplest choice.
Working in a team or using Git: use .pbip.
Delivering the same report to many clients: create a .pbit template.
Making setup easier for a colleague: share a .pbids file.
Need a chart Power BI doesn't include: import a .pbiviz visual.
Reviewing or editing the model inside a project: open the .tmdl files.
Editing pages, visuals or filters inside a project: use the .pbir definition.
Working with an older project or tool: you will meet .bim.
Each file type solves a different problem, from simple sharing with .pbix to team-friendly development with .pbip. Choosing the right one makes reports easier to build, review and reuse.
Delivering the same Power BI report to many tenants doesn't have to mean maintaining many semantic models. When the reporting logic is identical and only the data location changes, one parameterized model can serve every tenant. We learned this while building a reconciliation report for a multi-tenant data migration. Every tenant needed the same answer: did all the data arrive at the destination intact? Rather than cloning and editing a model for each tenant, we built one reusable model and moved the tenant-specific details into Power Query parameters. Here's how it works, and why it made onboarding a routine task instead of a development project. The challenge: The report had the same purpose for every tenant: compare source and destination data after migration and identify any discrepancies. However, each tenant had its own schemas. Without parameterization, onboarding a new tenant would require manually updating schema references throughout the model. As more tenants were added, this would create multiple copies of essentially the same model. This also increases the risk of inconsistencies. A fix applied to one model may not be applied to another, and over time the reports can start behaving differently. We wanted a process that was repeatable, consistent, and easy to maintain. The approach: Power Query parameters We added two parameters to the semantic model, and they became the only tenant-specific configuration: SourceSchema identifies the tenant's source schema. DestinationSchema identifies the tenant's destination schema. The server and database connection stay the same for everyone. Only the schema values change. Tenant SourceSchema DestinationSchema Customer A CustomerA_Source CustomerA_Destination Customer B CustomerB_Source CustomerB_Destination Every query in the model references these parameters instead of a hardcoded schema name. Tenant details become configuration, and the reporting logic stays untouched. Onboarding a new tenant in nine steps With the reusable model in place, adding a tenant follows the same checklist every time: Download or prepare the existing semantic model. Rename it for the new tenant. Copy the required report visuals into the new file, if needed. Publish the report to the right Power BI workspace. Open the model's transformation or parameter settings. Set SourceSchema and DestinationSchema to the new tenant's values. Apply the changes. Refresh the model. Validate the reconciliation results. No queries are rebuilt and no report pages are redesigned. The administrator changes two values and validates the output. Consistency, governance, and a word on security One of the biggest advantages of this approach is consistency. Every tenant can use the same semantic model design and reconciliation logic. Tenant-specific values are kept in parameters instead of being scattered throughout the queries. This also makes the process easier to document. The organization can define who is responsible for onboarding tenants, who can change parameters, how refreshes are performed, and what validation is required after each deployment. At the same time, tenant data isolation still needs to be handled through the appropriate database and Power BI security and permission model. Parameters should be treated as configuration, not as the only security control. Business benefits A parameter-driven model pays off in practical ways: Faster onboarding, because there is little to no development per tenant. Consistent reporting, because every tenant shares one model and one set of calculations. Lower maintenance, because a fix is made once and applies everywhere. Fewer configuration errors, because no one is hand-editing dozens of queries. Better scalability, because the effort per tenant stays flat as the tenant count grows. Simpler administration, through a documented, repeatable onboarding process. Above all, adding a tenant becomes an operational task rather than another development project. Conclusion When several tenants need the same Power BI reporting experience, a separate model per tenant usually isn't necessary. If the database structure is consistent and the main difference is the schema, Power Query parameters make one semantic model reusable across all of them. With SourceSchema and DestinationSchema as the only tenant-specific settings, the reconciliation logic stays standardized and onboarding stays repeatable. The result is one model, configurable tenant values, and reporting that scales with your tenant base.
Introduction Imagine managing hundreds of shipment requests every week. Emails keep arriving, spreadsheets grow larger every day, vendor quotes come from multiple sources, and teams spend hours manually updating records and tracking approvals. What starts as a simple shipping process can quickly become a complex operational challenge. For many logistics and supply chain teams, this is a daily reality. Manual processes often lead to delayed shipments, duplicate records, missed communications, and limited visibility into the overall shipping lifecycle. As businesses grow, these challenges become even more difficult to manage efficiently. But what if shipment requests could be automatically processed the moment they arrive? What if vendor quotes could be extracted, organized, and matched to shipments without manual effort? And what if approvals, tracking, and updates happened seamlessly through intelligent automation? This is where Artificial Intelligence (AI) and cloud-based automation are transforming modern logistics operations. In this blog, we’ll explore how two intelligent solutions: the Shipping Log Agent and the Shipping Quote Agent, work together to automate shipment creation, vendor quote management, approvals, and booking processes. Built on a modern Azure-based architecture, these AI-powered agents help organizations reduce manual work, improve accuracy, accelerate decision-making, and create a more efficient logistics operation from end to end. The Challenge Many organizations still rely on emails, spreadsheets, and manual workflows to manage shipment requests and vendor quotations. As shipment volumes increase, teams spend significant time reviewing documents, entering data, comparing quotes, coordinating approvals, and updating shipment records. These manual processes often result in: Duplicate shipment records Delayed approvals and bookings Data entry errors Limited visibility across shipment activities Increased operational workload Slower response times to customers and vendors As logistics operations grow, these inefficiencies become increasingly difficult to manage and can directly impact service quality, costs, and operational performance. The Solution: AI-Powered Automation The solution combines Artificial Intelligence, workflow automation, and cloud-native technologies to streamline the entire shipping lifecycle. Instead of manually reviewing documents, extracting shipment details, managing vendor quotes, and coordinating approvals, the system automates these activities using AI-powered agents. The solution consists of two specialized AI-powered agents that work together to automate critical logistics processes: Shipping Log Agent: The Shipping Log Agent automates the processing of shipment requests received through email. How It Works When a shipment request email arrives, the agent automatically: Monitors and identifies shipment request emails Reads PDF and Excel attachments Uses AI to understand and extract shipment information Converts unstructured documents into structured shipment records Applies intelligent matching rules to identify potential duplicates Creates new shipment records or updates existing ones Routes exceptions through an approval workflow when required Stores validated data securely in a centralized SQL database By eliminating manual document processing, the Shipping Log Agent significantly improves efficiency while maintaining data quality. Shipping Quote Agent: Once shipment requests are approved, the Shipping Quote Agent streamlines the collection and evaluation of vendor quotations. How It Works The Shipping Quote Agent automatically: Generates quote requests for approved shipments Sends requests to vendors Receives vendor responses through email Extracts pricing information from PDF quotations using AI Categorizes freight charges and surcharges Matches quotes with corresponding shipment requests Routes quotes for coordinator review and approval Updates shipment records after approval This automation eliminates the need for manual quote comparison and data entry, reducing delays and administrative effort. Key Enhancements and Innovations Migration from Excel-based storage to SQL Database AI-driven document processing Intelligent shipment matching Automated approval workflows Record versioning and locking Improved scalability and performance Complete audit trail Conclusion As logistics operations become more complex, organizations need smarter ways to manage shipment workflows. The Shipping Log Agent and Shipping Quote Agent demonstrate how AI-powered automation can streamline operations, improve accuracy, and support scalable business growth. By combining Azure services with intelligent document processing, organizations can build a more efficient and future-ready logistics ecosystem.