Merge pull request #1526 from MicrosoftDocs/master

Manas update

Author: jimholtz

powerapps-docs/developer/common-data-service/webapi/web-api-types-operations.md

@@ -2,7 +2,7 @@
 title: "Web API types and operations (Common Data Service)| Microsoft Docs"
 description: "This topic describes what is available for you to use vis-a-vis the Web API and will introduce important topics and how you can find information you need from the documentation generated from the service and metadata documents as well as the documentation of the system entity types, functions, and actions"
 ms.custom: ""
-ms.date: 04/22/2019
+ms.date: 04/30/2019
 ms.service: powerapps
 ms.suite: ""
 ms.tgt_pltfrm: ""
@@ -267,7 +267,7 @@ OData supports a wide range of data types but Common Data Service doesn’t use
 
 ### Lookup properties
 
-For most single-valued navigation properties you will find a computed, read-only property that uses the following naming convention: `_<name>_value` where the `<name>` 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 <xref href="Microsoft.Dynamics.CRM.incident?text=incident EntityType" /> [Single-valued navigation properties](/dynamics365/customer-engagement/web-api/incident?view=dynamics-ce-odata-9#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 [<xref href="Microsoft.Dynamics.CRM.incident?text=incident EntityType" /> [Properties](/dynamics365/customer-engagement/web-api/incident?view=dynamics-ce-odata-9#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.  
+For most single-valued navigation properties you will find a computed, read-only property that uses the following naming convention: `_<name>_value` where the `<name>` 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 <xref href="Microsoft.Dynamics.CRM.incident?text=incident EntityType" /> [Single-valued navigation properties](/dynamics365/customer-engagement/web-api/incident?view=dynamics-ce-odata-9#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 <xref href="Microsoft.Dynamics.CRM.incident?text=incident EntityType" /> [Properties](/dynamics365/customer-engagement/web-api/incident?view=dynamics-ce-odata-9#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.  
 

powerapps-docs/maker/dev-community-plan.md

@@ -7,7 +7,7 @@ manager: kvivek
 ms.service: powerapps
 ms.topic: conceptual
 ms.custom: canvas
-ms.date: 05/01/2016
+ms.date: 04/30/2019
 ms.author: iyanni
 ms.reviewer:
 
@@ -46,8 +46,8 @@ With the individual environment, you get the following functionality:
 | **Key features** | |
 | Create and run apps |Yes. You can create unlimited apps |
 | Share apps\* |No |
-| Use the Common Data Service |Yes** |
-| Model your data using the Common Data Service |Yes** |
+| Use the Common Data Service |Yes |
+| Model your data using the Common Data Service |Yes|
 | Enterprise-grade administration of the environment and user policies |Yes |
 | **Connectivity** | |
 | Connect to Office 365, Dynamics 365, and other connectors |Yes |
@@ -56,9 +56,9 @@ With the individual environment, you get the following functionality:
 | Access on‐premises data using an on-premises gateway |Yes |
 | Create custom connectors to connect to your own systems |Yes. You can create unlimited custom connectors |
 | **Common Data Service** | |
-| Create and run applications on the Common Data Service |Yes** |
-| Model your data in the Common Data Service |Yes** |
-| Create a database in the Common Data Service |Yes** |
+| Create and run applications on the Common Data Service |Yes |
+| Model your data in the Common Data Service |Yes |
+| Create a database in the Common Data Service |Yes |
 | **Management** | |
 | Add co-workers as environment makers and admins |No |
 | Add co-workers to the database roles |No |
@@ -67,8 +67,6 @@ With the individual environment, you get the following functionality:
 
 *You can't share apps, flows, connections, etc. with any other users of your tenant. You also can't add any other user as an environment admin or maker, or to the database roles from the admin center.
 
-\*\*Creating a database with the Common Data Service is currently unavailable in an individual environment, and will be available again soon. If you had created a database earlier, then you can continue using it without any issues. 
-
 ## What are the capacity limits for the individual environment?
 
 | **Capacity** |  |