The document outlines the Common Data Service (CDS) as a central platform for business applications, enabling integration of various data sources and simplifying app development. It details features like the Common Data Model, data security, user roles, and integration capabilities with Microsoft tools. Furthermore, it highlights the evolution of CDS and its future expansion with enhanced functionality and additional entities.

1. 25-05-2017

2. •Perguntar por slides
•Colocar o logo do SQL Port
•Colocar o título correto

3. About Me
•14 years in Microsoft technologies
• 6 years in Web, Desktop e Mobile
• 8 working with CRMs
•Head of Business Applications at Findmore (Nearshore Portugal)
•Microsoft Partner company focused on providing CRM solutions,
Sharepoint, Office 365 and Azure. Focus on Nearshore.
•Business Solutions MVP 4.0 (Dynamics CRM)

4. Agenda
•Business Application Platform
•Dynamics 365
•What is?
•Why the Common Data Service?
•The Common Data Model
•Data Types; Properties
•Security
•Integration
•SDK
•Future
Common Data Service

5. Business Application Platform

6. Dynamics 365

7. What is?
•Wouldn’t life be easier if everything just worked together?
•Platform that enables customers to easily build the business apps and
processes they need.
•Brings together your business data in one place so you can focus on the
things that matter: building apps, finding insights and automating your
business processes
•Going to be the backbone of future for business data.
•Business application model and storage mechanism

8. What is?
•Common Data Service (CDS) contains a Common Data Model (CDM)
•Technologies
•Azure infrastructure, an easy to provision, yet scalable data store (Service Fabric;
Elastic SQL)
•Integrations use M-engine (sits under power query), DIXF & OData under the hood!
•M is the language used to move and transport data to and from CDS

9. Why the Common Data Service?
•A common data model with standard entity schema and behavior
•Set of standard entities deployed within every database
•Integration with Microsoft Office for Excel and Outlook
•SDK for professional development scenarios
•Roles
•Power Users – provides extensibility & enables point solutions via PowerApps, Flow,
PowerBI
•IT Admin – manage your company’s data and processes centrally. Security, roles,
etc. applied consistently across all apps & services.
•ISV App Developers – build your apps once with CDS and we’ll do the rest of the
heavy lifting.
•LOB App Developers – build your apss on top of all your company’s data in one place

10. Why the Common Data Service?

11. The Common Data Model

12. The Common Data Model
•Provides a shared representation of the data that matters to your apps
•Consists of standard, extensible, commonly used entities across business
and productivity applications.
•Applications can work against data without needing to explicitly know
where that data is coming from
•You can…
•Create custom entities
•Perform bulk data import export through the PowerApps portal
•Leverage field groups to drive default PowerApps behavior
•Use Standard Picklists & create your own
•Analyse data in Power BI Perspectives for standard entities

13. The Common Data Model
• Structured metadata
• Entities are structured with data definition, behavior modeling and defaulting.
• Rich data types
• Address, Email, Currency, Auto-numbering. Modern types such as images,
geographic location, Phone, Website
• Data constructs
• Support for modeling relationships, lookups, aggregates, containment etc.
• System attributes (for concurency management, security, and audit trails)
• RecordVersion, RecordId, DataPartition, CreatedByUser, CreatedByDateTime,
ModifiedByUser, ModifiedByDateTime.
• Entity and field level security can be configured per entity

14. The Common Data Model
• Data validation for mandatory and unique field data and checking for
invalid foreign key references
• Data encryption at rest

15. Why use Standard entities?
•Translations for standard entity names and fields into local languages
•Field Groups to identify key fields for create, details and reporting scenarios
•Predefined sample data
•Security permission sets
•Relationships to each other to support common business processes
•Can be extended with custom fields to support
•ISVs and other developers can all work against a common set of data

16. Entity field data types I
Type Primitive Type Description
Address Compound separate fields for first line, second line, city, state/province, ...
AutoNumber String With prefix and an incrementing number. For example, “EXP001.”
BigInteger BigInteger RecordId - included as a system field in every entity. cannot create
Boolean Boolean True and False.
Currency Compound two fields(decimal value; enumeration for the currency code).
Date DateTime Only the Date portion of the DateTime type
DateTime DateTime A date that is combined with a time of day with fractional seconds.
Email String Email is stored as a string but is understood as a separate type
Guid Guid A guid.
Integer Integer An integer between -2,147,483,648 and 2,147,483,647.

17. Entity field data types II
Type Primitive Type Description
Lookup [Foreign key] The value matches the primary key in another table.
Multiline Text String Multiple lines of text.
Number Decimal can be stored 32 digits
PersonName Compound given name (first name), middle name, and surname (last name).
Phone String Phone is stored as a string but is understood as a separate type
Picklist Integer The integer serves as a reference into one of the standard picklists.
Quantity Quantity A decimal value.
Text String One line of text.
Url String Url is stored as a string but is understood as a separate type

18. Entity field properties
Property Applies To Description
Default value Text The default value of the Text field.
Max length Text The maximum number of characters in a text field.
Prefix Number Sequence The prefix that is used for the number sequence.
Picklist Picklist The option set type of the field.
Required All A value is required for the field.
Searchable All The data can be searched.
Unique All Values for the field must be unique across the entity.

19. Naming Conventions
•Entity names are singular
•Examples: Tenant, Family, SalesOrder.
•Entity ID names are created by appending “Id” to the entity name
•Examples: WorkerId, CaseId, FamilyId.
•Lookup fields are named with the entity name of the entity that they are
related to

20. Entity relationships and lookup fields
•Referential integrity
•Cascading delete
•Associated rows in the referencing entity
are deleted.
•Restricted delete
•Cannot delete a row in the referenced entity
if it has associated rows in the referencing
entity.
• Self => Supported
• One-to-one => Not Supported
• One-to-many => Supported
• Many-to-many => Not Supported

21. Database Security
•There are two modes in which the
Common Data Service can run:
•Open mode – the data stored in the
common data service is open to all
users. Everyone will always have the
needed permissions to use any app.
•Restricted mode – Grant specific
data permissions to users by using
the admin center. When running in,
you will need to configure the role-
based security.

22. Security Model
•Data in the Common Data Service can be secured at several levels:
•Database level – Admins can define which users can perform all administrative
operations in the Common Data Service.
•Entity level – Admins can define which users have access to entities, and what
actions those users can take on those entities
•Record level – Admins can use policies to define which records a user has access to
in a given entity.

23. User Roles
•User role are assigned to users or user groups within your organization to
provide them access to a collection of entities.
•The entities that a role provides access to are determined by the permission
sets that the role includes.
•There are two special roles that are provided by the Common Data Service
for your convenience.
•Database Owner – provides access to all entities in your database, even as new
custom entities are added. assign users to roles, and define the permissions for those
roles.
•Organization User – assigned to all users in your organization automatically. In
Restricted mode, everyone will need to be provided access to the entities that the
PowerApp is using.
•A user can be assigned multiple roles to allow access to different sets of

24. Permission Sets
•The standard entities have been grouped, and each group has two
permission sets :
•View – allows read-only access to the data within the entity
•Maintain – allows read, create, update and delete operations within the entity.
•A permission set is comprised of a list of entities and the level of access
granted for each entity.
•Create, read, update, and delete permissions can be granted to any entity
•To grant access to a custom entity you must provide an access level under
a permission set.

25. Policies - Record Level Sercurity (Preview)
•Determine the records that a user has access to within an entity
•The policy allows you to limit the data returned to the user. A policy
restricts access based on the value of a field within the record.
•Policies can be defined to only return values:
•With a given picklist value
•Where the current user of the application matches the user stored in the record
•Separate policies can be defined for each data operation: Create, Read,
Update, and Delete
•Security configuration can also be done in code via the Common Data
Service SDK

26. Data Import Export
•Standard and Custom entities
•Data import feature that allows hundreds of thousands of records to be
imported and exported efficiently.
•Exporting template files (Excel spreadsheets or CSV delimited) for entities
that match the schema of the target entity and can have a subset of the
entity fields
•The template designer let’s you pick fields that you care about and quickly add
required fields.
•Quickly and easily import data from your existing systems.
•Rapidly establishes trusted connections for IT-managed tenants.
•The trusted connections continually synchronize the data between your existing
systems and your platform solutions.

27. Integration
•Productivity add-ins to access your data from Microsoft Excel and Outlook.
•Your solutions can connect information from productivity platforms with
data from business applications.
•Connects through standard interfaces, such as the Microsoft Graph
•Maps entities to the productivity platform objects to enable the join relationships
with business data.

28. Excel Add-in
•All standard and custom entities can be interactively viewed and edited in
Excel
•Excel Add-in that provides data entry with data-type specific assistance for
picklists, dates and lookups

29. Outlook Add-in
•Data from the Common Data
Service related to the people in
emails and meetings
•In this first release, the Outlook
Add-in only looks for related data in
a few entities such as Cases
•End-users can manage the relevant
data in the CDS without your LOB
app or IT department needing to lift
a finger

30. Microsoft Dynamics 365 data integration
•The Prospect to Cash data
integration feature enables a
basic flow of account data and
other entity data to enable a
prospect-to-cash scenario.
•The data integration feature is
available to customers who
have at least one Dynamics
365 product

31. How to build and manage apps?
• For the low-code/novice app creator
• PowerApps - Drag and drop to create your apps on data from the CDS
• Power-up your Powerapps by building complex logic with the C# SDK and host it in
an Azure Function
• For the professional developer
• Rich C# SDK – enables you to build complex web apps or rich client applications.
• Environments group features together in CDS including:
• A collection of tables and table relationships
• Publishing Power Apps
• Integration and mapping tools connected to Dynamics 365

32. Example of Business Applications
•Dynamics 365 for Retail
•Dynamics 365 for Talent

33. SDK I
•Allows create, read, update, delete (CRUD) and even query your business
data residing in the Common Data Service
•The client and the server tiers communicate through JSON documents that
describe the operations required
•Is viable create applications by building the JSON documents with string
operations and using standard HTTP protocols to transmit them over the
wire to the Common Data System endpoints
•Advantage of API is a higher abstraction level, offering a strong type system to help
you at design time rather than running the risk of failing at runtime
•It is useful to think of these SDKs as domain-specific languages (DSLs)
implemented in their host languages.
•In the terminology of the SDK, tables are called entitysets, as opposed to
entities. Entities are in turn the records in the entitysets.

34. SDK II
•Authentication of the user is against Azure Active Directory
•Almost all the methods provided by the SDK are available as asynchronous
methods
•The types representing entitysets are merely C# classes without much
fanfare (POCOs)
•In the SDK the concept of transactions does not exist:
•We have to add all the entities to an executor. The executor is then responsible for
managing the transaction in the most effective manner
•The server layer will deserialize the entities, start a transaction, insert the records,
and commit the transaction

35. SDK – Query Data I
•Almost all the methods provided by the SDK are available as asynchronous
methods
•The types representing entitysetsare merely C# classes without much
fanfare (POCOs)
•No option for specifying "all fields", since misuse caused performance
issues in other systems
var query = client.GetRelationalEntitySet<ProductCategory>()
.CreateQueryBuilder()
.Where(pc => pc.Name == "Surface" || pc.Name == "Phone")
.Project(pc => pc.SelectField(f => f.CategoryId).SelectField(f => f.Name));

36. SDK – Query Data II
•Joining data from multiple entitysets
•Joins – entitysets carry with them a lot of metadata that describes the relationships
among them, you typically don't have to specify the fields that are used to do the join
in the query.
•Zips
•If you haven't modeled any relationships. For this purpose, you can use the Zip
clause, where you specify both the joined entityset and the relationship that defines
the join.
•Grouping data
•Using aggregates
•This approach is preferable to manual aggregation, because the data isn't
transported over the wire, and the aggregations are done very quickly.
•Paging
•Able to fetch a certain number of records after several records have been skipped. To
achieve this result, you can add Take and Skip clauses to the query.

37. Generally Available
• Improved app from data generation on standard and custom entities with
field groups
• Multi-field lookups
• Editable data import/export entity field mappings
• Ability to export data import/export templates
• Multi-sheet Excel import
• Simplified address type, complex types for Quantity, Person name, GUID,
Date
• Central place to view entity relationships

38. Generally Available
• Simplified primary key definition
• Searchable fields allow for indexed searches
• Entity data explorer in creator portal
• Null support
• Default value support for simple data types
• Manage Custom Picklists

39. PowerBI (Preview)
•Power Apps Common Data Service (CDS) connector to Power BI desktop
•This means your data model and all the data in it is natively accessible in Power BI
Desktop
•Secured with the roles and policies IT Pros have defined in CDS
•Reports reflect real time data
•There’s no need to schedule a refresh in Power BI. When the data is updated in CDS,
changes are reflected in reports
•Power BI is aware of rich data types and relationships defined in CDS
•These types are recognized by Power BI as first class data types.
•For an example, when you report using an address field, Power BI shows a map as a default
visualization.
•Entities are presented by subject areas (perspectives)
•While CDS contains a rich set of entities representing many business areas
•Entities are organized into a set of ready-made subject areas called Perspectives. A
perspective offers a “view into data” from a reporting point of view.

40. Future I
•Common Data Model will grow from 70+ entities today to 300+ entities in
the next quarter
•Security
•Column level security
•Add the ability for IT Pros to secure data based on even more advanced business
artifacts and concepts such as hierarchies, regions and business units.
•Multiple Dynamics 365 applications and offerings that are built on this
Common Data Service. These apps build on the CDS, so the data that’s used
by those apps are available for you to build your own apps against.
•Make PowerApps + CDS even simpler, by introducing more powerful out-of-
the-box forms that will automatically configure based on entity metadata
and relationships
•Improved import/export capabilities so you can choose which entities and

41. Future II
•With Dynamics 365 for Sales or Operations, or even Azure Active Directory
and Office 365, we’re making it so that your data just shows up in the
Common Data Service.
•Working with the Office 365 team so that business processes and apps can
use productivity artifacts like calendar events and tasks natively in their
apps
•Working very closely with the Microsoft Graph team so that the data we
bring together in CDS is exposed via the Graph for apps that are already built
using the Graph REST APIs or SDKs
•Working with partners like Microsoft StaffHub to automatically integrate
data from your Dynamics services to enhance users’ StaffHub experiences

42. Future III

43. Pricing

44. Resources
•PowerApps Blog
•https://powerapps.microsoft.com/en-us/blog/
•Entity Reference Guide
•http://download.microsoft.com/download/8/9/5/8956ED58-A9B0-40DF-8CB0-
BC13AD8DB6E2/CDMEntityReference.docx
•Preview Program
•cdspreviewprogs@microsoft.com

45. Contacts
•azevedo.dev@gmail.com
•http://www.psazevedo.com/
•http://xptcrm.com/
•@azevedo_pedro

46. Questions?

47. CONTACTS
http://www.psazevedo.com/
pedro.azevedo@findmore.eu
http://xptcrm.com/
@azevedo_pedro