In this session I presented how Common Data Service will be the future of Business Application Platform and how this platform will help the Dynamics 365 to grow.

1. TUGA IT 2017
LISBON, PORTUGAL

2. THANK YOU TO OUR SPONSORS
PLATINUM
GOLD SILVER

3. PARTICIPATING COMMUNITIES
CLOUD
PRO
PT

4. About me
• 13 years in Microsoft technologies
• 6 years in Web, Desktop e Mobile
• 7 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 3.0 (Dynamics CRM)

5. • 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
Agenda

6. Business Application Platform

7. Dynamics 365
Line-of-Business
Applications
built in-house

8. 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

9. 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

10. 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

11. Why the Common Data Service?

12. The Common Data Model

13. 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

14. 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
• 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 entities.
When running a PowerApp, the user’s access to data will be the combination of
all roles they are assigned.

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 ImportExport
• 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 entitysetsare 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
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));
• 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

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
• 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

38. 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.

39. 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
security artifacts (roles, etc.) you want to export from your development
environment!

40. 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

41. Future III

42. Pricing

43. 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

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

45. Questions?

46. PLEASE FILL IN EVALUATION FORMS
FRIDAY, MAY 19th SATURDAY, MAY 20th
https://survs.com/survey/cprwce7pi8 https://survs.com/survey/l9kksmlzd8
YOUR OPINION IS IMPORTANT!

47. THANK YOU TO OUR SPONSORS
PLATINUM
GOLD SILVER