Power apps Guide

Official documents belong to MANUAL Type document , I hope the learning curve is smoother , Quick start , So I extracted important paragraphs and combined them into my own TUTORIAL, Then read the official website documents from simple to profound .

In fact, many textbooks are translated , patchwork , Add an example , Finally, pass the knowledge points of essence “ own ” The understanding of the , Explain it again . Here, I will directly bold the key parts of the original text , No knowledge is reprocessed .

Learning ideas ：

1. First understand the general structure of the official documents （API、 Concept 、get start、 Community ）
API Part only needs to understand its function ; Important big concepts must be made clear , Make an impression of unimportant concepts , We'll go into it later ;get start Some are very friendly to novices , Required reading ; Community , Errata and other parts follow the fate of Kangkang .

2. Be clear about your needs （ This part sometimes becomes difficult , Because demand is not necessarily the actual project output , Requirements can be solutions , At this time, it is necessary to have a certain understanding of the system ）

3. Read official documents according to your own needs （ It is more efficient to read with emphasis ）

4. Complete a general understanding of , Directly implement , Direct query of project problems , You can refer to the documentation 、 Community, etc. （ The purpose of this is to learn documents driven by products , This stage can quickly improve the understanding of documents and systems ）

6. Read and understand the document several times later （ After having a comprehensive understanding and implementation of the project , Reading the document again will lead to a lot of deep thinking ）

https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/

1.Power Apps

https://docs.microsoft.com/en-us/powerapps/powerapps-overview

1.1 Brief

WHAT:

Power Apps is a suite of apps, services, connectors and data platform that provides a rapid application development environment to build custom apps for your business needs.

---

ADVANTAGE:

a. Using Power Apps, you can quickly build custom business apps that connect to your business data stored either in the underlying data platform (Common Data Service) or in various online and on-premises data sources (SharePoint, Excel, Office 365, Dynamics 365, SQL Server, and so on).

b. Apps built using Power Apps provide rich business logic and workflow capabilities to transform your manual business processes to digital, automated processes.

c. Further, apps built using Power Apps have a responsive design, and can run seamlessly in browser or on mobile devices (phone or tablet).

d. Power Apps “democratizes” the custom business app building experience by enabling users to build feature-rich, custom business apps without writing code.

e. Power Apps also provides an extensible platform that lets pro developers programmatically interact with data and metadata, apply business logic, create custom connectors, and integrate with external data.

---

1.2 Power Apps for app makers/creators

Using Power Apps, you can create three types of apps: canvas, model-driven, and portal. More information: Overview of creating apps in Power Apps.

1.3 Power Apps for app users

1.4 Power Apps for admins

1.5 Power Apps for developers

Developers are app makers who can write code to extend business app creation and customization. Developers can use code to create data and metadata, apply server-side logic using Azure functions, plug-ins, and workflow extensions, apply client-side logic using JavaScript, integrate with external data using virtual entities and webhooks, build custom connectors, and embed apps into your website experiences to create integrated solutions. More information: Power Apps for developers

1.6 Power Apps and Dynamics 365

Dynamics 365 applications, such as Dynamics 365 Sales, Dynamics 365 Customer Service, Dynamics 365 Marketing also use the underlying data platform (Common Data Service) used by Power Apps to store and secure data. This enables you to build apps using Power Apps and Common Data Service directly against your core business data already used within Dynamics 365 without the need for integration. More information: Dynamics 365 and Common Data Service

1.7 Power Apps and Common Data Service

Common Data Service is the underlying data platform for Power Apps that contains the core functionality such as server-side logic (plug-ins and workflows), business process flows, a highly sophisticated security model, and an extensible platform for developers to build apps.

1.8 Learning catalog for Power Apps

https://docs.microsoft.com/en-us/powerapps/learning-catalog/get-started

2.Common Data Service(CDS)

https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/data-platform-intro

2.1 What is Common Data Service?

Common Data Service lets you securely store and manage data that’s used by business applications.Data within Common Data Service is stored within a set of entities. An entity is a set of records used to store data, similar to how a table stores data within a database. Common Data Service includes a base set of standard entities that cover typical scenarios, but you can also create custom entities specific to your organization and populate them with data using Power Query. App makers can then use Power Apps to build rich applications using this data.

---

2.2 Why use Common Data Service?

Standard and custom entities within Common Data Service provide a secure and cloud-based storage option for your data. Entities let you create a business-focused definition of your organization’s data for use within apps. If you’re not sure if entities are your best option, consider these benefits:

Easy to manage – Both the metadata and data are stored in the cloud. You don’t need to worry about the details of how they’re stored.

Easy to secure – Data is securely stored so that users can see it only if you grant them access. Role-based security allows you to control access to entities for different users within your organization.

Access your Dynamics 365 Data – Data from your Dynamics 365 applications is also stored within the Common Data Service allowing you to quickly build apps which leverage your Dynamics 365 data and extend your apps using Power Apps.

Rich metadata – Data types and relationships are leveraged directly within Power Apps.

Logic and validation – Define calculated fields, business rules, workflows, and business process flows to ensure data quality and drive business processes.

Productivity tools – Entities are available within the add-ins for Microsoft Excel to increase productivity and ensure data accessibility.

2.2 Dynamics 365 applications and Common Data Service

a. Relationship

Dynamics 365 applications, such as Dynamics 365 Sales, Dynamics 365 Customer Service or Dynamics 365 Talent, also use the Common Data Service to store and secure data used by the applications.

This enables you to build apps using Power Apps and the Common Data Service directly against your core business data already used within Dynamics 365 without the need for integration.

---

b. Advantages

Build Apps against your Dynamics 365 Data – Build apps quickly against your business data within Power Apps or using the Pro Developer SDK.

Manage reusable Business logic and rules – Business Rules and logic already defined in your Dynamics 365 entities are applied to your Power Apps to ensure data consistency regardless of how your users are accessing the data or through which app.

Reusable skills across Dynamics 365 and Power Apps – Users with skills previously in Power Apps or Dynamics 365 can now leverage those skills across the Common Data Service platform. Creating entities, forms, charts, etc are now common across your applications.

2.3 Integrating Data into the Common Data Service

a. Relationship

Building an app typically involves data from more than one source, while this can sometimes be done at the application level, there are also cases where integrating this data together into a common store allows for an easier app building experience, and a single set of logic to maintain and operate over the data. Common Data Service allows data to be integrated from multiple sources into a single store which can then be used in Power Apps, Power Automate, Power BI, and Power Virtual Agents along with data already available from the Dynamics 365 applications.

---

b. Advantages

Scheduled integration with other systems – Data which is kept within another application can be regularly synchronized with the Common Data Service to allow you to leverage other applications data in Power Apps.

Transform and import data using PowerQuery – Transforming data when importing into the Common Data Service can be done through PowerQuery from many online data sources, a common tool used across Excel and Power BI.

One time import of data – Simple import and export of Excel and CSV files can be used for a one time or infrequent import of data into the Common Data Service.

---

For more information about integrating data into the Common Data Service, see Add data to an entity in Common Data Service by using Power Query.

2.4 Interacting with entities

When you develop an app, you can use standard entities, custom entities, or both. Common Data Service provides standard entities by default. These are designed, in accordance with best practices, to capture the most common concepts and scenarios within an organization.

2.5 Logic and validation

2.6 Security

2.7 Developer capabilities

In addition to the features available through the Power Apps portal, Common Data Service also includes features for developers to programmatically access metadata and data to create entities and business logic, as well as interact with data.

---

For more information, see Common Data Service Developer Overview

3.Entity

3.1 Attributes

Attributes are listed in two separate sections: Writable attributes and Read-only attributes

3.2 Relationships

The relationships exist between the entities.
The EntityMetadata class includes three properties to represent relationships:

A. OneToManyRelationships

B. EntityMetadata.ManyToOneRelationships

C. EntityMetadata.ManyToManyRelationships

4.Way to Integrate Data

Way to Integrate Data into the Common Data Service

4.1 Brief

Common Data Service allows data to be integrated from multiple sources into a single store which can then be used in Power Apps, Power Automate, Power BI, and Power Virtual Agents along with data already available from the Dynamics 365 applications.

4.2 Ways

A. Scheduled integration with other systems
Data which is kept within another application can be regularly synchronized with the Common Data Service to allow you to leverage other applications data in Power Apps.

B. Transform and import data using PowerQuery Transforming data when importing into the Common Data Service can be done through PowerQuery from many online data sources, a common tool used across Excel and Power BI.

C. One time import of data
Simple import and export of Excel and CSV files can be used for a one time or infrequent import of data into the Common Data Service.

5.Common Data Service Developer Guide

5.1 Brief

There are many aspects to how developers can contribute to creating apps that use Common Data Service. While it is possible to build an application with code using Common Data Service as your data source, most projects will use either model-driven apps or canvas apps to generate the experience that people will use.

5.2 Canvas apps

Design and build a business app from a canvas in Microsoft Power Apps without writing code in a traditional programming language such as C#. Design the app by dragging and dropping elements onto a canvas, just as you would design a slide in PowerPoint. Create Excel-like expressions for specifying logic and working with data.

5.3 Model-driven apps

If you don’t need a custom design and your data is in Common Data Service, you can automatically generate a model-driven app from your business data and processes. This type of app can model forms, views, and other components, and the default UI automatically adjusts to phones, laptops, and other devices.

---

Model-driven app design is a component-focused approach to app development. Model-driven app design doesn’t require code and the apps you make can be simple or very complex. Unlike canvas app development where the designer has complete control over app layout, with model-driven apps much of the layout is determined for you and largely designated by the components you add to the app.
At a fundamental level, model-driven app making consists of three key focus areas:

A. Modeling business data

B. Defining business processes

C. Composing the app

---

Model-driven apps are built on Common Data Service, and can only connect to a Common Data Service environment. All the data that defines a model-driven app is stored within Common Data Service.

Model-driven apps share the method of distributing customizations and extensions used by Common Data Service using Solutions.

---

Model driven apps also have a number of points for developers to write code to extend. For information on what developers can do with model-driven apps, see Model-driven apps Developer Guide.

---

Some examples of model-driven apps available from Microsoft are Dynamics 365 Customer Service, Dynamics 365 Field Service, and Dynamics 365 Marketing.

5.4 Note

Because Common Data Service includes many capabilities for people to configure custom business logic without writing code, the most common scenarios for developers to contribute involve filling spaces in-between where existing features may not provide functionality you need to meet a requirement. Fortunately, Common Data Service provides many points for developers to extend the common functionality using code.

---

For a developer who will contribute to projects it is important that they understand what can be done without writing code. You should familiarize yourself with these capabilities. More information: What is Common Data Service?

---

Common Data Service is not available for on-premise deployments at this time.Content in this guide does not include information about options that are only available for on-premises or internet facing deployments (IFD). For information related to these options, see the Developer Guide for Dynamics 365 Customer Engagement (on-premises).

6.Developers: Get started with Common Data Service

Where to start depends on what problem you are trying to solve.

6.1 Work with data using Web services

Common Data Service provides two web services that you can use to interact with data: Web API and Organization Service.

A. Web API
The Common Data Service Web API provides a development experience that can be used across a wide variety of programming languages, platforms, and devices. The Web API implements the OData (Open Data Protocol), version 4.0, an OASIS standard for building and consuming RESTful APIs over rich data sources.The Web API allows you to do all the same operations as the organization service but presents them in an RESTful style.OData v4 provides for named operations via functions or actions.Most messages available in the organization service are exposed as a corresponding named function or action.

B.Organization service

C. Web API and the Organization service
The Web API provides a RESTful programming experience but ultimately all data operations go through the underlying organization service.

6.2 Applying business logic

6.3 Integrate with external data

6.4 Common Data Service entities

6.5 Work with metadata

6.6 Use solutions to package and distribute extensions

6.7 Create client applications and authentication

7.Supported Customizations for Common Data Service

7.1 Brief

You can customize Common Data Service by using tools that are available in the Power Apps portal or that are described in the official documentation. These customizations are supported and can be upgraded.

---

Customizations made using methods other than those described here are unsupported and could cause problems during updates and upgrades to Common Data Service. For more information, see Unsupported Customizations.

7.2 Customizations using Power Apps portal

7.3 Customizations applied using code

A. Solution file

a. Modification of an unmanaged solution file is supported as described in this documentation. Certain customization tasks for model-driven apps can be performed using these steps:
1.Export a solution component as an unmanaged solution.
2.Extract the contents of the solution package.
3.Edit the Customizations.xml file.
4.Repackage the solutions file.
5.Import the modified solution.

b. The following supported tasks can be performed using this procedure:
1.Ribbon customization.
2.Application navigation customization using SiteMap.
3.Form and dashboard customization using FormXml.
4.Saved query customization.

---

B. Plug-ins
The ability to create custom business logic using the plug-in mechanism described in this documentation is fully supported and upgradeable. Plug-ins can only be registered and executed in the sandbox (isolation). More information: Plug-ins

A plug-in is a .NET assembly that you can upload to the Common Data Service.

---

C. Workflow extensions
The ability to create custom workflow activities (assemblies) to be called from workflow rules is fully supported and upgradeable. Custom workflow activities can only be registered and executed in the sandbox (isolation). More information: Workflow extensions

7.4 Support for .NET Framework Versions

7.5 Unsupported customizations

Modifications to Common Data Service that are made without using either the methods described in this documentation or Common Data Service tools are not supported and are not preserved during updates or upgrades of Common Data Service. Anything that is not documented in this documentation and supporting documents is not supported. Additionally, unsupported modifications could cause problems when you update through the addition of hotfixes or service packs or upgrade Common Data Service.

The following is a list of unsupported action types that are frequently asked about:…

8.Work with data using code

Use web services to work with data in Common Data Service

Common Data Service provides two web services that you can use to interact with data: Web API and Organization Service. Choose the one that best matches the requirement and your skills.

8.1 Web API

The Web API is an OData v4 RESTful endpoint. Use this for any programming language that supports HTTP requests and authentication using OAuth 2.0.

More information: Use the Common Data Service Web API

8.2 Organization service

Use the .NET Framework SDK assemblies for projects that involve writing plug-ins or workflow extensions.

More information: Use the Common Data Service Organization Service.

Note:
Use the Xrm.Tooling assemblies if you are creating a Windows client application. More information: Build Windows client applications using the XRM tools.

9.Use the Common Data Service Web API

9.1 Brief

The Web API is one of two web services you can use to work with data and metadata in Common Data Service. The other is the Organization Service.

---

The Common Data Service Web API provides a development experience that can be used across a wide variety of programming languages, platforms, and devices. The Web API implements the OData (Open Data Protocol), version 4.0, an OASIS standard for building and consuming RESTful APIs over rich data sources. You can learn more about this protocol at https://www.odata.org/. Details about this standard are available at https://www.oasis-open.org/standards#odatav4.0.
Because the Web API is built on open standards, we don’t provide assemblies for a specific developer experience. You can compose HTTP requests for specific operations or use third-party libraries to generate classes for whatever language or platform you want. You can find a list of libraries that support OData version 4.0 at https://www.odata.org/libraries/.

9.2 Web API and the Organization service

It is valuable to recognize that the organization service is what defines the platform. The Web API provides a RESTful programming experience but ultimately all data operations go through the underlying organization service. The organization service defines the supported operations as messages. Each message has a name. These names are bound to the events used in the event framework to evaluate what registered extensions should be initiated. More information: Event Framework

---

The Web API allows you to do all the same operations as the organization service but presents them in an RESTful style. OData v4 provides for named operations via functions or actions. Most messages available in the organization service are exposed as a corresponding named function or action. Those messages that correspond to CRUD operations are not available in the Web API because as a RESTful service they have implementations using GET, POST, PATCH, and DELETE HTTP methods, but within the platform the retrieve, create, update, and delete messages are invoked just as they are when the corresponding operations are performed using the .NET Framework assemblies.

10. Get started with Common Data Service Web API (C#)

This section shows you how to access the Common Data Service Web API using the C# programming language. The first topic, Quick Start: Web API sample (C#), provides the quickest example of how to accomplish this, as all source code is simplified and provided in one file. The rest of this section shows you how to create and configure Visual Studio projects that use the Common Data Service Web API to perform common business data operations.

After completing this guide, you will have learned enough to explore the many other business operations that are supported by the Common Data Service Web API. You will also have a better understanding about how the Web API Samples (C#) are structured.

10.1 Quick Start: Web API sample (C#)

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/webapi/quick-start-console-app-csharp

10.2 Enhanced quick start (C#)

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/webapi/enhanced-quick-start

10.3 Start Web API project in Visual Studio

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/webapi/start-web-api-project-visual-studio-csharp

11.Authenticate

Authenticate to Common Data Service with the Web API

？？？

12.Web API types and operations

https://xxxcom/api/data/v9.0

12.1 Terminology

The Web API is implemented using the OData v4 standard which uses a specific set of terms you need to be familiar with. Entity Data Model (EDM) is the abstract data model that is used to describe the data exposed by an OData service. The following table is a selected list of terms defined in OData Version 4.0 Part 1: Protocol Plus Errata 02 which you should understand.

12.2 Service documents

There are two service documents you can reference to learn more about the Web API.

a. Service document
The following query, typed into the address field of your browser, returns the service document, a complete list of all the entity sets that are available for your organization.

[Organization URI]/api/data/v9.0

The entity sets are returned in the form of a JSON array. Each item in the array has three properties as listed in this table.

This information can be retrieved using a GET request and may be useful to get a list of all entity sets available using the service.

b. CSDL $metadata document

A GET request to the following URL will return a rather large (more than 3.5 MB) Common Schema Definition Language (CSDL) document, or metadata document that describes the data and operations exposed by the service.

GET [Organization URI]/api/data/v9.0/$metadata

This document can be used as a data source to generate classes that will provide strongly typed objects for the service. But if you are not using generated classes, you may want to review documentation generated from this information instead. The Web API Reference uses information primarily from this document taken from a system with common additional solutions installed.

You can learn more about this document in OData Version 4.0 Part 3: Common Schema Definition Language (CSDL) Plus Errata 02.

Note: Metadata annotations

The metadata document includes several types of Annotation elements which provide additional information about metadata elements and the capabilities of the service. Starting with v9.x, these annotations are not included with the default metadata document unless explicitly requested. These annotations increase the size of the metadata document and are not always necessary.

To include annotations you have two options when requesting the metadata document:

Append the ?annotations=true query string parameter to the URL.
Add the Prefer: odata.include-annotations="" header to the request.*

---

Each Annotation element includes a Term attribute that describes the type of annotation. The definitions of all the possible annotations used by OData v4 can be found in OData Vocabularies Version 4.0. The following table provides some examples used by the Web API.

12.3 Entity types

The following is the definition of the account EntityType from the $metadata with properties and navigation properties removed.

XML
-------------
<EntityType Name="account" BaseType="mscrm.crmbaseentity">  
  <Key>  
    <PropertyRef Name="accountid" />  
  </Key>  
  <!--Properties and navigation properties removed for brevity-->  
  <Annotation Term="Org.OData.Core.V1.Description" String="Business that represents a customer or potential customer. The company that is billed in business transactions." />  
</EntityType>

Each EntityType reference page in the SDK documentation uses information from the $metadata to show the following information when available.

---

a. Web API Metadata EntityType Reference：
Metadata entity types represent the types used in the Microsoft Dynamics CRM metadata model.

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/web-api/metadataentitytypes?view=dynamics-ce-odata-9

b. The Web API EntityType Reference：
An EntityType represents an entity type in the OData v4 entity mode

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/web-api/entitytypes?view=dynamics-ce-odata-9

c. Change the name of an entity set
By default, the entity set name matches the EntityMetadata EntityType LogicalCollectionName (EntityMetadataLogicalCollectionName) property value. If you have a custom entity that you want to address using a different entity set name, you can update the EntityMetadata EntityType EntitySetName (EntityMetadata.EntitySetName) property value to use a different name.

d. Alternate keys
None of the system entities have alternate keys defined. If you define alternate keys for an entity, they will be included in the $metadata EntityType element as an Annotation like the following:

<Annotation Term="OData.Community.Keys.V1.AlternateKeys">  
  <Collection>  
    <Record Type="OData.Community.Keys.V1.AlternateKey">  
      <PropertyValue Property="Key">  
        <Collection>  
          <Record Type="OData.Community.Keys.V1.PropertyRef">  
            <PropertyValue Property="Alias" String="key name" />  
            <PropertyValue Property="Name" PropertyPath="key name" />  
          </Record>  
        </Collection>  
      </PropertyValue>  
    </Record>  
  </Collection>  
</Annotation>

Information about alternate keys can also be retrieved from the metadata using the EntityMetadata EntityType Keys collection-valued navigation property using the Web API or the EntityMetadata.Keys property using the organization service.

e. Type inheritance
Inheritance allows for sharing of common properties and categorizing entity types into groups. All entity types in the web API inherit from two of the following entity types. All business entity types inherit from the crmbaseentity EntityType and all model entities inherit from the crmmodelbaseentity EntityType.

12.4 Properties

Each entity type may have declared properties that correspond to attributes. In the Web API EntityType Reference and Web API Metadata EntityType Reference content, properties that are inherited from a base entity type are combined within the list of declared properties for each entity type. The inheritance is called out in the description for each property.

In the $metadata EntityType elements each property is included in a Property element with a Name attribute value that corresponds to the properties you will set in code. The Type attribute value specifies the data type of the property. Properties for business entity types generally use OData primitive types.

---

The following is an example of the account EntityType name property defined in the $metadata.

<Property Name="name" Type="Edm.String" Unicode="false">  
  <Annotation Term="Org.OData.Core.V1.Description" String="Type the company or business name." />  
</Property>

The description of the property is available in an Annotation element with the Term attribute property of Org.OData.Core.V1.Description. This description is taken from the AttributeMetadata EntityType Description property value. Not all properties have a description.

---

Each property may be computed. This means that the value may be set by the system. This is specified in an Annotation element with the Term attribute value of Org.OData.Core.V1.Computed.

Each property may also have limitations on whether it may be updated. This is defined in an Annotation element with a Term attribute value Org.OData.Core.V1.Permissions. The only option set for this is Org.OData.Core.V1.PermissionType/Read, which indicates that the property is read only.

a. Primitive types
OData supports a wide range of data types but Common Data Service doesn’t use all of them. The following table describes how Common Data Service Organization service types are mapped to OData primitive types.

b. Lookup properties
?
For most single-valued navigation properties you will find a computed, read-only property that uses the following naming convention: __value where the matches the name of the single-valued navigation property. The exception to this pattern is when a lookup attribute of the entity can accept multiple types of entity references. A common example is how the incident entity customerid attribute may be set to a reference that is either a contact or account entity. In the incident EntityType Single-valued navigation properties you will find customerid_account and customerid_contact as separate single-valued navigation properties to reflect the customer associated with an opportunity. If you set one of these single-valued navigation properties, the other will be set to null because they are both bound to the customerid attribute. In the incident EntityType Properties you’ll find a _customerid_value lookup property that contains the same value that is set for whichever of the single-valued navigation properties contain a value.

Generally, you should avoid using lookup properties and use the corresponding single-valued navigation properties instead. These properties have been included because they may be useful for certain integration scenarios. These properties are read-only and computed because they will simply reflect the changes applied using the corresponding single-valued navigation property.

When you include lookup properties in a query, you can request annotations to be included that provide additional information about the data that is set for those underlying attributes which aren’t represented by a single-valued navigation property. More information:Retrieve data about lookup properties

12.5 Navigation properties

In OData, navigation properties allow you to access data related to the current entity. When you retrieve an entity you can choose to expand navigation properties to include the related data. There are two types of navigation properties: single-valued and collection-valued.

a. single-valued

These properties correspond to Lookup attributes that support many-to-one relationships and allow setting a reference to another entity.

<NavigationProperty Name="createdby" Type="mscrm.systemuser" Nullable="false" Partner="lk_accountbase_createdby">  
 <ReferentialConstraint Property="_createdby_value" ReferencedProperty="systemuserid" />  
</NavigationProperty>

Every navigation property that represents a single-valued navigation property will have a corresponding collection-valued navigation property indicated by the Partner attribute value. Each single-valued navigation property also has a ReferentialConstraint element with Property attribute value that represents the computed read-only lookup property that can be used to retrieve corresponding GUID value of the related entity. More information:Lookup properties.

b. collection-valued

These properties correspond to one-to-many or many-to-many relationships. In the $metadata EntityType element, these are defined as a NavigationProperty element with at Type attribute set to a collection of a type. The following represents the account EntityType Account_Tasks collection-valued navigation property which represents a one-to-many relationship:

<NavigationProperty Name="Account_Tasks" Type="Collection(mscrm.task)" Partner="regardingobjectid_account_task" />

When the collection-valued navigation property represents a many-to-many relationship, the name of the navigation property and the name of the partner will be the same. The following represents the account EntityType accountleads_association collection-valued navigation property which represents a many-to-many relationship:

<NavigationProperty Name="accountleads_association" Type="Collection(mscrm.lead)" Partner="accountleads_association" />

The difference between one-to-many and many-to-many relationships is not important when using the Web API. The way you associate entities is the same regardless of the type of relationship. Although many-to-many relationships still use intersect entities behind the scenes, only a few special system intersect entities are included within the Web API EntityType Reference. For example, campaignactivityitem EntityType is technically an intersect entity, but it is included because it has more properties than an ordinary intersect entity.

An ordinary intersect entity has only the four basic properties required to maintain the many-to-many relationship. When you create a custom many-to-many relationship between entities, an ordinary intersect entity will be created to support the relationship. Because you should use navigation properties to perform operations involving many-to-many relationships, ordinary intersect entities are not documented but are still available using the Web API. These intersect entity types are accessible using an entity set name that uses the following naming convention: +’collection’. For example, you can retrieve information from the contactleads intersect entity type using [Organization URI]/api/data/v9.0/contactleadscollection. You should only use these ordinary intersect entities in situations where you wish to apply change tracking.

12.6 Actions

Actions are operations that allow side effects, such as data modification, and cannot be further composed in order to avoid non-deterministic behavior.

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/webapi/use-web-api-actions

12.7 Functions

There are two types of functions defined in the Web API:

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/webapi/use-web-api-functions

a. Web API Function Reference:
The Web API Function Reference lists each of the available system functions.

b. The Web API Query Function Reference
The Web API Query Function Reference topic lists functions which are intended to be used as criteria in a query.

12.8 Complex types

Complex types are keyless named structured types consisting of a set of properties. Complex types are commonly used as property values in model entities, or as parameters or return values for operations.

<ComplexType Name="WhoAmIResponse">  
  <Property Name="BusinessUnitId" Type="Edm.Guid" Nullable="false" />  
  <Property Name="UserId" Type="Edm.Guid" Nullable="false" />  
  <Property Name="OrganizationId" Type="Edm.Guid" Nullable="false" />  
</ComplexType>

12.9 Enumeration types

Enumeration types or EnumTypes are named primitive types whose values are named constants with underlying integer values.

Web API EnumType Reference :

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/web-api/enumtypes?view=dynamics-ce-odata-9

e.g:
The following is the AccessRights EnumType from the $metadata.

<EnumType Name="AccessRights">  
  <Member Name="None" Value="0" />  
  <Member Name="ReadAccess" Value="1" />  
  <Member Name="WriteAccess" Value="2" />  
  <Member Name="AppendAccess" Value="4" />  
  <Member Name="AppendToAccess" Value="16" />  
  <Member Name="CreateAccess" Value="32" />  
  <Member Name="DeleteAccess" Value="65536" />  
  <Member Name="ShareAccess" Value="262144" />  
  <Member Name="AssignAccess" Value="524288" />  
</EnumType>

13.Perform operations using the Web API

The Web API provides a modern, RESTful web service you can use to interact with data in Common Data Service using a wide variety of platforms, programming languages and devices.

NOTE:
Information under this section is also applicable to the Dynamics 365 Customer Engagement (on-premises) users.

13.1 Compose HTTP requests and handle errors

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/webapi/compose-http-requests-handle-errors

13.2 Query Data using the Web API

If you want to retrieve data for an entity set, use a GET request.
When retrieving data, you can apply query options to set criteria for
the data you want and the entity properties that should be returned.

13.3 Retrieve related entity records with a query

14.Retrieve an entity record using the Web API

Use a GET request to retrieve data for an entity specified as the resource with a unique identifier. When retrieving an entity record you can also request specific properties and expand navigation properties to return properties from related entities.

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/webapi/retrieve-entity-using-web-api

15.Perform conditional operations using the Web API

Common Data Service provides support for a set of conditional operations that rely upon the standard HTTP resource versioning mechanism known as ETags.

15.1 ETags

Common Data Service generates a weakly validating @odata.etag property for every entity instance, and this property is automatically returned with each retrieved entity record. For more information, see Retrieve an entity using the Web API.