other edits

Author: HeidiSteen

articles/search/search-how-to-create-search-index.md

@@ -20,17 +20,13 @@ Unless you are using an [indexer](search-howto-create-indexers.md), creating an
 
 ## Prerequisites
 
-Write permissions on the search service are required for creating and loading indexes. Most operations will require that you provide an [admin API key](search-security-api-keys.md) on the create index request. Alternatively, if you're participating in the Azure Active Directory [role-based access control public preview](search-security-rbac.md), you can issue your request as a member of the Search Contributor role.
+Write permissions are required for creating and loading indexes, granted through an [admin API key](search-security-api-keys.md) on the request. Alternatively, if you're participating in the Azure Active Directory [role-based access control public preview](search-security-rbac.md), you can issue your request as a member of the Search Contributor role.
 
 Index creation is largely a schema definition exercise. Before creating one, you should have:
 
-+ A clear idea of which fields you want to make searchable, retrievable, filterable, facetable, and sortable in your index.
++ A clear idea of which fields you want to make searchable, retrievable, filterable, facetable, and sortable in your index (discussed in [schema checklist](#schema-checklist)).
 
-  The [field attribute assignments](search-what-is-an-index.md#index-attributes) will determine both search behaviors, and the physical representation of your index on the search service. During design and development, start with sample data so that you can drop and rebuild the index easily as you finalize field attribution.
-
-+ A source field that uniquely identifies each row, record, or item in the source data. For example, if you're indexing from Blob Storage, the storage path is often used as the document key. 
-
-  Every index requires one field that serves as the *document key* (sometimes referred to as the "document ID"), and this key is mapped to a source field containing a unique identifier. The ability to uniquely identify specific search documents is required for retrieving a specific document in the search index, and for selective data processing at the per-document level.
++ A single source field that uniquely identifies each row, record, or item in the source data, to be used as the document key (or ID) in the index. For example, if you're indexing from Blob Storage, the storage path is often used as the document key. 
 
 + Index location. Moving an existing index to a different search service is not supported out-of-the-box. Revisit application requirements and make sure the existing search service, its capacity and location, are sufficient for your needs.
 
@@ -64,12 +60,16 @@ Use this checklist to help drive the design decisions for your search index.
 
 1. Review [naming conventions](/rest/api/searchservice/naming-rules) so that index and field names conform to the naming rules.
 
-1. Review [supported data types](/rest/api/searchservice/supported-data-types). The data type will impact how the field is used. For example, numeric content is filterable but not full text searchable.
+1. Review [supported data types](/rest/api/searchservice/supported-data-types). The data type will impact how the field is used. For example, numeric content is filterable but not full text searchable. The most common data type is `Edm.String` for searchable text, which is tokenized and queried using the full text search engine.
 
-1. Identify one field in the source data that contains unique values, allowing it to function as the key field in your index.
+1. Identify one field in the source data that contains unique values, allowing it to function as the key field in your index. 
+
+  Every index requires one field that serves as the *document key* (sometimes referred to as the "document ID"). The key should be mapped to the unique identifier in your source data. The ability to uniquely identify specific search documents is required for retrieving a specific document in the search index, and for selective data processing at the per-document level.
 
 1. Identify the fields in your data source that will contribute searchable content in the index. Searchable content includes short or long strings that are queried using the full text search engine. If the content is verbose (small phrases or bigger chunks), experiment with different analyzers to see how the text is tokenized.
 
+   [Field attribute assignments](search-what-is-an-index.md#index-attributes) will determine both search behaviors and the physical representation of your index on the search service. Determining how fields should be specified is an iterative process for many customers. To speed up iterations, start with sample data so that you can drop and rebuild easily.
+
 1. Identify which source fields can be used as filters. Numeric content and short text fields, particularly those with repeating values, are good choices. When working with filters, remember:
 
    + Filterable fields can optionally be used in faceted navigation.