Skip to content

Commit 52ac647

Browse files
tapanm-MSFTtapanm-MSFT
committed
Merge branch 'master' into portals-1914373
2 parents d2f01b0 + d6f5091 commit 52ac647

File tree

8 files changed

+197
-14
lines changed

8 files changed

+197
-14
lines changed

‎powerapps-docs/developer/common-data-service/TOC.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,8 @@
2727
href: use-fetchxml-left-outer-join-query-records-not-in.md
2828
- name: Page large result sets with FetchXML
2929
href: org-service/page-large-result-sets-with-fetchxml.md
30+
- name: Paging behaviors and ordering
31+
href: org-service/paging-behaviors-and-ordering.md
3032
- name: Use column comparison in queries
3133
href: column-comparison.md
3234
- name: "Use SQL to query data (Preview)"

‎powerapps-docs/developer/common-data-service/org-service/page-large-result-sets-with-fetchxml.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -108,7 +108,9 @@ while (true)
108108
}
109109
```
110110

111-
### See also
111+
### See also
112+
113+
[Paging behaviors and ordering](paging-behaviors-and-ordering.md)
112114
[Sample: Use FetchXML with a Paging Cookie](samples/use-fetchxml-paging-cookie.md)
113115
[Building Queries with FetchXML](/dynamics365/customer-engagement/developer/org-service/build-queries-fetchxml)
114116
[Fiscal date and older than datetime query operators in FetchXML](../use-fetchxml-fiscal-date-older-datetime-query-operators.md)

‎powerapps-docs/developer/common-data-service/org-service/paging-behaviors-and-ordering.md

Lines changed: 179 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,179 @@
1+
---
2+
title: "Paging behaviors and ordering (Common Data Service) | Microsoft Docs" # Intent and product brand in a unique string of 43-59 chars including spaces
3+
description: "Learn about the different paging behaviors for FetchXML queries and how you can write queries to get the desired paging results." # 115-145 characters including spaces. This abstract displays in the search result.
4+
ms.custom: ""
5+
ms.date: 7/20/2020
6+
ms.reviewer: "pehecke"
7+
ms.service: powerapps
8+
ms.topic: "article"
9+
author: "NHelgren" # GitHub ID
10+
ms.author: "nhelgren" # MSFT alias of Microsoft employees only
11+
manager: "mayadu" # MSFT alias of manager or PM counterpart
12+
search.audienceType:
13+
- developer
14+
search.app:
15+
- PowerApps
16+
- D365CE
17+
---
18+
19+
# Paging behaviors and ordering
20+
21+
When querying data using FetchXML, paging query results can make viewing large
22+
volumes of information easier. It is important when using paging to include
23+
ordering parameters as well. Without proper ordering, paging requests for the
24+
“next 50” records can result in retrieving the same records across multiple
25+
pages making reviews and edits much more difficult. Proper page ordering
26+
requires including unique values to help identify which records are included in
27+
a page.
28+
29+
## Legacy paging
30+
31+
Legacy paging within the Common Data Service loads all the results of the query
32+
up to the current page into memory on the server, selects the number of records
33+
that are needed for the page, and then ignores the rest. This has benefits such
34+
as quick back/forward paging through the data or skipping to a specific page,
35+
but it also has restrictions such as a 50K row limit, performance issues with
36+
large complex queries, and arbitrarily sorted distinct query results.
37+
38+
## Ordering with a paging cookie
39+
40+
When paging with ordering, a cache of the previous page’s results is stored in a
41+
paging cookie. This is used to calculate what the next page of data should
42+
display.
43+
44+
If a user does not specify any “order by” parameters, the system will
45+
automatically insert “order by "\<\<entity name\>\>".\<\<entityId\>\> asc” to
46+
provide some basic ordering. Depending on the data that is being queried, this
47+
may result in inadequate and unexpected results as a single system user can be
48+
associated with multiple records within any query.
49+
50+
If distinct FetchXML queries are being used, the system will not add any
51+
additional ordering due to potential impacts to the data returned. In these
52+
cases, users will have to add at least a single ordering value for a more
53+
consistent paging experience.
54+
55+
> [!NOTE]
56+
> Paging using FetchXML for Common Data Service is dynamic. The page a
57+
> record appears on is determined at the time that each page is rendered. If 1000
58+
> records are being displayed 50 to a page, the first 50 records are displayed as
59+
> page one. When page two is requested, the system determines what the next 50
60+
> records should be at the time of request. Because of this, it would not be
61+
> possible to use the new paging functionality for back paging. Legacy behavior is
62+
> used for back paging which will have reduced performance and any returns after
63+
> page 500 cannot be “paged back” due to legacy limitations. 
64+
65+
### Why ordering is important
66+
67+
If a query is run to retrieve all records with a state of “Open” this could
68+
result in 1000 returns. When paging from page one to page two, there is no way
69+
for the system to know which orders to display on page two because all of the
70+
records have the same state. The paging of these records will not be efficient
71+
or consistent.
72+
73+
Providing an “order by” value gives the paging cookie the ability to order the
74+
data by an additional value and recognize the last record in a page based on the
75+
values provided.
76+
77+
#### Example 1
78+
79+
A query is created to get all records with a state of ‘Open’, include the status
80+
for every record, and show three records per page. The query is then ordered by
81+
status. The query result would page as shown in the following table:
82+
83+
| State | Status | Page |
84+
|-----------|------------|---------------|
85+
| Open | Active | 1 |
86+
| Open | Active | 1 |
87+
| Open | Active | End of page 1 |
88+
| Open | Active | |
89+
| Open | Active | |
90+
| Open | Inactive | |
91+
| Open | Inactive | |
92+
93+
The paging cookie will save information about the last record on the page, but
94+
when it’s time to get page two in this example, there is no unique identifier to
95+
ensure that the next page populated uses the unviewed records or include the
96+
first two records that were on page one.
97+
98+
To solve this problem, queries should include “order by” columns that have
99+
unique values. It is possible to use multiple “order by” values. Below is a
100+
better way to order data for this query:
101+
102+
#### Example 2
103+
104+
A query is created to get all records of a state of ‘Open’, any status, include
105+
the Case IDs, and show three records per page. It orders by status and by Case
106+
ID (a unique identifier) which will order in ascending order. The query result
107+
would page the results as shown below:
108+
109+
| State | Status | Case ID | Page |
110+
|-----------|------------|-------------|---------------|
111+
| Open | Active | Case-0010 | 1 |
112+
| Open | Active | Case-0021 | 1 |
113+
| Open | Active | Case-0032 | End of Page 1 |
114+
| Open | Active | Case-0034 | |
115+
| Open | Active | Case-0070 | |
116+
| Open | Inactive | Case-0015 | |
117+
| Open | Inactive | Case-0047 | |
118+
119+
The query results are first ordered by the Status, and then ordered by the Case
120+
ID in ascending order. When page two is generated, the result would be as shown
121+
below:
122+
123+
| State | Status | Case ID | Page |
124+
|-----------|------------|-------------|---------------|
125+
| Open | Active | Case-0010 | |
126+
| Open | Active | Case-0021 | |
127+
| Open | Active | Case-0032 | End of Page 1 |
128+
| Open | Active | Case-0034 | 2 |
129+
| Open | Active | Case-0070 | 2 |
130+
| Open | Inactive | Case-0015 | |
131+
| Open | Inactive | Case-0047 | |
132+
133+
When generating page two of this query set, the cookie will have Case-0032
134+
stored as the last record in the first page, so page two will pick up at the
135+
next record in the set after that record. This will allow for more consistent
136+
results.
137+
138+
### Ordering suggestions
139+
140+
Listed below are some suggestions for improving ordering of paging results, along with some areas to avoid.
141+
142+
#### Best ordering
143+
144+
- Always include a column that has a unique identifier (i.e., entity ID
145+
columns, auto-number columns, user/contact IDs)
146+
147+
#### Good ordering
148+
149+
- Include multiple fields that will most likely result in unique combinations:
150+
- First name + last name + email address
151+
- Full name + email address
152+
- Email address + company name
153+
154+
#### Poor ordering
155+
156+
- Orders that do not include unique identifiers
157+
158+
- Orders that have single or multiple fields that are not likely to provide
159+
uniqueness such as:
160+
- Status and state
161+
- Option sets or booleans
162+
- Name values by themselves (i.e., last only, first only, company name
163+
only)
164+
- Text fields like titles, descriptions, multi-line text
165+
- Non unique number fields
166+
167+
### Ordering and multiple entity queries
168+
169+
Sometimes data is needed that spans multiple entities and must be queried with a
170+
table JOIN. In these cases, ordering can be included for both entities in the
171+
query. Make sure to use at least one column with a unique ID per entity to
172+
ensure the paging provides the best results. However, the query will be
173+
downgraded to legacy paging, where no paging cookie will be returned, in these
174+
cases due to limitations of the N:1 relationship structure that could result in
175+
missing data.
176+
177+
### See Also
178+
179+
[Page large result sets with FetchXML](page-large-result-sets-with-fetchxml.md)

‎powerapps-docs/maker/common-data-service/create-edit-entities-solution-explorer.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -76,7 +76,7 @@ In the **General** tab, some of the options are required before you can save the
7676
|**Display Name**|This is the singular name for the entity that will be shown in the app.<br />This can be changed later.|
7777
|**Plural Name**|This is the plural name for the entity that will be shown in the app.<br />This can be changed later.|
7878
|**Name**|This field is pre-populated based on the display name you enter. It includes the solution publisher customization prefix.|
79-
|**Ownership**|You can choose either user or team-owned or organization owned. More information: [Entity ownership](types-of-entities.md#entity-ownership)|
79+
|**Ownership**|You can choose either user or team-owned or organization owned. More information: [Standard entity ownership](types-of-entities.md#standard-entities)|
8080

8181
## Edit an entity
8282

‎powerapps-docs/maker/common-data-service/types-of-entities.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -24,24 +24,24 @@ search.app:
2424
---
2525
# Types of entities
2626

27-
Before creating or editing entities in Common Data Service, you should understand that there are different types of entities. Once a custom entity is created, these types cannot be changed. The two major divisions are based on entity ownership and whether the entities are activity entities.
27+
Before creating or editing entities in Common Data Service, you should understand that there are different types of entities. Once a custom entity is created, these types can't be changed. The two main entity types are standard entities and activity entities.
2828

2929
<a name="BKMK_EntityOwnership"></a>
3030

31-
## Entity ownership
31+
## Standard entities
3232

33-
There are four different types of entity ownership. When you create a custom entity the only options are **user or team owned** or **organization-owned**, but you should be aware that other entities have different ownership types.
33+
There are four different types of standard entity ownership. When you create a custom standard entity the only options are **User or team** owned or **Organization** owned, but you should be aware that other entities have different ownership types.
3434

3535
|Ownership|Description|
3636
|---------------|-----------------|
3737
|**Business-owned**|Data in these entities belongs to the Business unit. Access to the data can be controlled at the business unit level.|
3838
|**None**|Data not owned by another entity.|
39-
|**Organization-owned**|Data belongs to the organization. Access to the data is controlled at the organization level.|
40-
|**User or Team Owned**|Data belongs to a user or a team. Actions that can be performed on these records can be controlled on a user level.|
39+
|**Organization**|Data belongs to the organization. Access to the data is controlled at the organization level.|
40+
|**User or team**|Data belongs to a user or a team. Actions that can be performed on these records can be controlled on a user level.|
4141

4242

4343
> [!IMPORTANT]
44-
> After an entity is created, you can’t change the ownership. Before you create an entity, make sure that you choose the correct type of ownership. If you later determine that your custom entity must be of a different type, you have to delete it and create a new one.
44+
> After a standard entity is created, you can’t change the ownership. Before you create an entity, make sure that you choose the correct type of ownership. If you later determine that your custom entity must be of a different type, you have to delete it and create a new one.
4545
4646
<a name="BKMK_ActivityEntities"></a>
4747

‎powerapps-docs/maker/portals/configure/azure-ad-b2c.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ author: sandhangitmsft
55
ms.service: powerapps
66
ms.topic: conceptual
77
ms.custom:
8-
ms.date: 01/03/2020
8+
ms.date: 07/21/2020
99
ms.author: sandhan
1010
ms.reviewer: tapanm
1111
---
@@ -107,7 +107,7 @@ You can create or configure the following site settings in portals to support [!
107107
| Authentication/Registration/ExternalLoginEnabled | Enables or disables external authentication. |
108108
| Authentication/Registration/AzureADLoginEnabled | Enables or disables [!include[Azure](../../../includes/pn-azure-shortest.md)] AD as an external identity provider. By default, it is set to true. |
109109
| Authentication/OpenIdConnect/[Federation-Name]/ExternalLogoutEnabled | Enables or disables federated sign-out. When set to true, users are redirected to the federated sign-out user experience when they sign out from the portal. When set to false, users are signed out from the portal only. By default, it is set to false. |
110-
| Authentication/LoginTrackingEnabled | Enables or disables tracking the user's last sign-in. When set to true, the date and time are displayed in the **Last Successful Sign-in** field on the contact record. By default, this is set to false. |
110+
| Authentication/LoginTrackingEnabled (Deprecated) | Enables or disables tracking the user's last sign-in. When set to true, the date and time are displayed in the **Last Successful Sign-in** field on the contact record. By default, this is set to false. Login tracking is deprecated. For more information, go to [Login tracking FAQ](../faq.md#login-tracking-enabled). |
111111
| Authentication/OpenIdConnect/[Federation-Name]/RegistrationEnabled | Enables or disables the registration requirement for the existing identity provider. When set to true, registration is enabled for the existing provider only if the site setting Authentication/Registration/Enabled is also set to true. By default, it is set to true. |
112112
|Authentication/OpenIdConnect/[Federation-Name]/PostLogoutRedirectUri |Specifies the URL within the portal to redirect to after a user signs out. |
113113
| | |

‎powerapps-docs/maker/portals/configure/web-files.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ author: sandhangitmsft
55
ms.service: powerapps
66
ms.topic: conceptual
77
ms.custom:
8-
ms.date: 11/04/2019
8+
ms.date: 07/21/2020
99
ms.author: sandhan
1010
ms.reviewer: tapanm
1111
---
@@ -51,7 +51,7 @@ The table below explains many of the standard web file attributes used by portal
5151
| Display Order | An integer value indicating the order in which the file will be placed, relative to other entities with the same Parent Page. This controls the ordering of files and other site map entities when, for example, a list of links to the child entities of a given page are rendered on the portal. |
5252
| Cloud Blob Address | A text value in the format `<container>/<filename>`, indicating that the content for this file is stored in Azure Blob Storage. |
5353
| Content-Disposition | Options are inline or attachment. If inline is specified, the browser should attempt to render it within the browser window and if it cannot, it will prompt the user to download or open the file. If attachment is specified, it will immediately prompt the user to download or open the file, and not try to load it in the browser, whether it can or not. |
54-
| Enable Tracking | If enabled, every request for this web file will be logged. A Web File Log record will be created with the date & time, IP Address, and the contact record if the user is authenticated. |
54+
| Enable Tracking (Deprecated) | If enabled, every request for this web file will be logged. A Web File Log record will be created with the date & time, IP Address, and the contact record if the user is authenticated. Web file tracking is deprecated. For more information, go to [Web file tracking FAQ](../faq.md#web-file-tracking-enabled). |
5555
|||
5656

5757

0 commit comments

Comments
 (0)