This post is a part of a series of 5 post exploring the key things you need to know about, when getting started with building model-driven apps on the Power Platform.
1. Working with solutions
2. Working with tables (this post)
3. Working with forms
4. Working with views
5. Working with the App Designer
UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
This is the first of 5 posts in my new series exploring the key things you need to know, as a citizen developer, when getting started with building model-driven apps, on the Power Platform.
1. Working with solutions (this post)
2. Working with tables
3. Working with forms
4. Working with views
5. Working with the App Designer
UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
Getting Start With Model-Driven Apps – Working with Tables
I recommend starting from the first post and working your way through them.
In my previous blog post, I explored the essentials of working with solutions on the Power Platform. Building on that knowledge, this post will focus on tables, a fundamental component of model-driven apps.
Tables are the foundation of data management in Dataverse (formerly CDS), providing a structured way to store and organize information. Understanding how they work and the objects they contain, is key to building great business applications.
The post is divided in to 4 areas:
1: Different types of tables
2: Basic objects that tables contain
3: Best practice when working with tables
4: Do’s and don’ts
1: Different types of tables
Tables in model-driven apps can be categorized into three main types:
1. Microsoft standard tables,
2. Custom tables, and
3. Virtual tables.
Microsoft standard tables come pre-built and are always available in Dataverse as part of any Power Platform environment. It is recommended that you use these as much as possible, if they make sense for the application you are building.
Custom tables are created to cater to specific business requirements. When designing custom tables, there are several things to keep in mind. Most importantly make sure that you use the correct publisher when creating tables, as well as the table elements, and also to create the elements within a solution. This will ensure you can track which objects are created by you or other citizen developers and which objects are standard Dataverse objects, present on the Power Platform.
Virtual tables, on the other hand, are tables that are not stored in the database but are generated dynamically based on defined criteria. This could be a SharePoint list, an SQL server or any other type of database you would want to use in your application.
2: Objects within tables
Tables contain various objects that help users with interacting with their data in a way that makes most sense for the purpose of the application. Citizen developers can apply a variety of different table objects to different areas of the application to make the experience as easy and efficient as possible. Some key objects to know are:
Columns
Columns define the attributes or fields that make up the table. Each column represents a specific data type, such as text, number, date/time, or lookup, and allows for data entry, validation, and calculations.
Forms
Forms provide the user interface for interacting with table records. They define the layout and presentation of data, including fields, sections, tabs, and subgrids. Forms allow users to view, create, update, and delete records. It is possible to create several different forms that can be used based on user roles/departments/or other groupings. Access to forms can be limited by security roles to ensure data quality and streamline the data input process for different user roles.
Views
Views determine how data from each table can be displayed in an easy overview. They define the columns, sorting, filtering, and other criteria for data retrieval. Views provide users with different perspectives on the data, helping them access and analyze information efficiently. It is possible to create multiple views for users depending on different roles or needs in the organization, and users can also create and save their own personal views.
Business Rules
Business rules are logical expressions that define automated behaviors within tables. They can change field visibility, set field values, do calculations, as well as other business logic. By applying business rules, you can ensure data integrity and streamline data entry processes.
3: Best Practice when working with tables
When working with tables, it’s important to follow best practices to maintain consistency, scalability, and performance. Here are some key considerations:
– Utilize Microsoft Standard Tables: Whenever possible, leverage Microsoft standard tables for core entities like contacts, accounts, and opportunities. These tables are designed following industry best practices and receive regular updates and enhancements.
– Create Custom Tables Sparingly: While custom tables provide flexibility, their creation should be limited to specific business requirements that cannot be met with existing standard tables. Overuse of custom tables can lead to complexity and maintenance challenges.
– Plan and Define Table Structures: Before creating tables, carefully analyze and plan the structure, relationships, and attributes required to store and manage data effectively. A well-defined table structure ensures data consistency and enables future scalability.
– Establish Naming Conventions: Consistent and meaningful naming conventions for tables, columns, and other objects enhance clarity and maintainability. Consider using prefixes or abbreviations to indicate the table’s purpose or module.
4: Do’s and Don’ts when working with tables
To maximize the efficiency and maintainability of your model-driven apps, keep the following do’s and don’ts in mind:
Do’s:
- Do define proper relationships between tables to ensure data integrity.
- Do use security roles and privileges to control access to tables and data.
- Do document your table structure, including relationships and customizations.
- Do use a structured and logical approach to creating columns, forms and views across your applications/solutions so avoid confusion.
Don’ts:
- Don’t modify or delete standard tables or columns provided by Microsoft.
- Don’t create unnecessary custom tables when existing standard tables can meet your requirements.
- Don’t overcomplicate table structures with excessive relationships or dependencies.
- Don’t overlook security considerations when granting table access to users.
There are some exceptions to the points of the do/don’t list. Modifying standard tables can be necessary in some cases. What is recommended there is considering if you want your application to use a variation of a standard form/view or to create a customized copy and work on that. Using any standard view/form/field from Microsoft ensures that is it updated and supported, however, any future update will also be included in your own application and could have an unintended effect on your application UI/UX.
Wrapping up
Understanding how to work with tables is important for new and experienced citizen developers. Tables are the building blocks of model-driven apps on the Power Platform, enabling efficient data management and app customization. By understanding the different types of tables, their constituent objects, adhering to best practices, and keeping in mind some general do’s and don’ts, you can develop robust and scalable applications that empower users to effectively interact with data.

Leave a reply to Getting started with model-driven apps – Working with the App Designer – Power Apps Viking Cancel reply