Dynamics 365 Virtual Entities - Simply Explained

1
00:00:00,000 --> 00:00:02,520
So what happens when a customer calls about an order,

2
00:00:02,520 --> 00:00:04,720
but the stock level lives in your warehouse system

3
00:00:04,720 --> 00:00:07,000
and the payment status, lives and finance?

4
00:00:07,000 --> 00:00:09,520
You can copy all that data into Dynamics 365,

5
00:00:09,520 --> 00:00:11,840
or you can ask your team to open three more systems.

6
00:00:11,840 --> 00:00:13,120
Neither option feels great.

7
00:00:13,120 --> 00:00:14,380
Here's the simple definition.

8
00:00:14,380 --> 00:00:17,060
Virtual entities, are you now often called virtual tables

9
00:00:17,060 --> 00:00:19,760
out, give Dynamics 365 a live window into data

10
00:00:19,760 --> 00:00:21,320
that already lives somewhere else?

11
00:00:21,320 --> 00:00:22,600
Welcome to another knowledge nugget.

12
00:00:22,600 --> 00:00:25,680
I'm Mirko Piedas from M365, FM, and today,

13
00:00:25,680 --> 00:00:27,500
we're breaking this down in plain English.

14
00:00:27,500 --> 00:00:28,480
We'll start with the problem,

15
00:00:28,480 --> 00:00:30,080
then look at the building blocks behind it

16
00:00:30,080 --> 00:00:32,360
when virtual tables fit and where they can cause trouble.

17
00:00:32,360 --> 00:00:36,280
Why copying data creates problems?

18
00:00:36,280 --> 00:00:40,160
Imagine a sales team working in Dynamics 365.

19
00:00:40,160 --> 00:00:42,160
They can see the customer, the opportunity,

20
00:00:42,160 --> 00:00:43,800
and every call they've logged.

21
00:00:43,800 --> 00:00:46,440
But the product catalog belongs in an ERP system.

22
00:00:46,440 --> 00:00:48,280
Stock levels sit in the warehouse system,

23
00:00:48,280 --> 00:00:49,800
invoices belong in finance.

24
00:00:49,800 --> 00:00:51,760
Each system owns part of the story.

25
00:00:51,760 --> 00:00:54,160
For years, the usual answer was copying records

26
00:00:54,160 --> 00:00:55,960
from one system into another.

27
00:00:55,960 --> 00:00:57,160
A job might run every night

28
00:00:57,160 --> 00:00:58,960
and bring product details, inventory numbers,

29
00:00:58,960 --> 00:01:01,240
or invoice status into Dynamics 365.

30
00:01:01,240 --> 00:01:04,240
That sounds simple until the data changes at lunchtime.

31
00:01:04,240 --> 00:01:07,400
A warehouse worker ships the last 10 units of a product.

32
00:01:07,400 --> 00:01:09,840
The ERP system knows the stock is now zero,

33
00:01:09,840 --> 00:01:12,520
but Dynamics 365 might still show 10 units

34
00:01:12,520 --> 00:01:14,280
until the next scheduled sink runs.

35
00:01:14,280 --> 00:01:16,480
Your salesperson sees stock that no longer exists,

36
00:01:16,480 --> 00:01:18,360
then there's the duplicate record problem.

37
00:01:18,360 --> 00:01:19,960
The product lives in the ERP system,

38
00:01:19,960 --> 00:01:22,000
but a copied version lives in DATAverse,

39
00:01:22,000 --> 00:01:25,160
the data foundation behind Dynamics 365 and Power Apps.

40
00:01:25,160 --> 00:01:27,800
When someone changes a description, price, or status,

41
00:01:27,800 --> 00:01:30,200
someone needs to decide which system should win.

42
00:01:30,200 --> 00:01:32,360
That question creates a lot of messy work.

43
00:01:32,360 --> 00:01:35,920
Think of it like keeping paper files in two filing cabinets.

44
00:01:35,920 --> 00:01:38,160
One in the sales office and one in the warehouse.

45
00:01:38,160 --> 00:01:40,280
Each time somebody changes a paper in one cabinet,

46
00:01:40,280 --> 00:01:42,640
they must carry an updated copy to the other cabinet.

47
00:01:42,640 --> 00:01:44,680
Miss one trip and the cabinets disagree.

48
00:01:44,680 --> 00:01:46,160
Sync jobs can fail too.

49
00:01:46,160 --> 00:01:48,200
A password changes, a connection breaks,

50
00:01:48,200 --> 00:01:50,200
a field changes in the source system.

51
00:01:50,200 --> 00:01:51,520
The job stops overnight

52
00:01:51,520 --> 00:01:53,480
and users may not notice until they start looking

53
00:01:53,480 --> 00:01:55,680
at wrong or missing records the next morning.

54
00:01:55,680 --> 00:01:58,160
Meanwhile, the people doing the work have their own problem.

55
00:01:58,160 --> 00:02:00,760
They open a customer in Dynamics 365,

56
00:02:00,760 --> 00:02:03,640
then switch to the ERP system to check stock.

57
00:02:03,640 --> 00:02:06,320
Next, they open a finance tool to check an invoice.

58
00:02:06,320 --> 00:02:08,080
Then they return to Dynamics 365

59
00:02:08,080 --> 00:02:09,560
and try to remember what they saw.

60
00:02:09,560 --> 00:02:11,560
That breaks the flow of the conversation.

61
00:02:11,560 --> 00:02:13,040
Now here's the thing, you don't always need

62
00:02:13,040 --> 00:02:14,440
a full copy of every record.

63
00:02:14,440 --> 00:02:16,440
Sometimes you only need to see the current answer

64
00:02:16,440 --> 00:02:17,720
while you work with the customer.

65
00:02:17,720 --> 00:02:19,720
For example, an account manager may need

66
00:02:19,720 --> 00:02:21,080
today's available quantity

67
00:02:21,080 --> 00:02:22,800
before promising a delivery date.

68
00:02:22,800 --> 00:02:24,800
The warehouse system should keep control of that number

69
00:02:24,800 --> 00:02:27,200
because it tracks goods moving in and out all day.

70
00:02:27,200 --> 00:02:30,560
Dynamics 365 doesn't need to become a second warehouse database.

71
00:02:30,560 --> 00:02:31,880
This is the choice that matters.

72
00:02:31,880 --> 00:02:34,920
Do you need Dynamics 365 to own a local copy of the data

73
00:02:34,920 --> 00:02:36,720
or do you need users to see the latest data

74
00:02:36,720 --> 00:02:38,360
from the system that already owns it?

75
00:02:38,360 --> 00:02:40,520
When copying ads more jobs, more duplicates

76
00:02:40,520 --> 00:02:42,640
and more chances for records to disagree,

77
00:02:42,640 --> 00:02:44,640
a live connection can be the cleaner path.

78
00:02:44,640 --> 00:02:46,680
The source system keeps the record.

79
00:02:46,680 --> 00:02:49,080
Dynamics 365 gives users a place to see it

80
00:02:49,080 --> 00:02:51,440
alongside their sales or service work.

81
00:02:51,440 --> 00:02:53,680
What a virtual entity actually is today.

82
00:02:53,680 --> 00:02:56,160
We, Udimer, talking about virtual tables.

83
00:02:56,160 --> 00:02:57,400
You might also hear them called

84
00:02:57,400 --> 00:03:00,480
virtual entities are the same concept, different name.

85
00:03:00,480 --> 00:03:03,840
A virtual table is a table definition inside dataverse

86
00:03:03,840 --> 00:03:05,920
that points to records stored somewhere else.

87
00:03:05,920 --> 00:03:07,680
Dataverse knows what the columns look like

88
00:03:07,680 --> 00:03:10,580
or product name available quantity, price, invoice,

89
00:03:10,580 --> 00:03:13,880
status, or but it does now to restore the actual data.

90
00:03:13,880 --> 00:03:16,400
Think of it as a blueprint, not the building itself.

91
00:03:16,400 --> 00:03:18,800
At first, that difference sounds small.

92
00:03:18,800 --> 00:03:20,520
Here are Timers the Thing.

93
00:03:20,520 --> 00:03:21,880
It changes everything.

94
00:03:21,880 --> 00:03:23,280
With a normal dataverse table,

95
00:03:23,280 --> 00:03:25,240
the data lives right inside dataverse.

96
00:03:25,240 --> 00:03:27,200
You create an account, contact, or case,

97
00:03:27,200 --> 00:03:28,520
and the record is stored there.

98
00:03:28,520 --> 00:03:30,520
With a virtual table, you only define the shape

99
00:03:30,520 --> 00:03:32,320
of what columns to show or and a path

100
00:03:32,320 --> 00:03:34,120
to where the real data actually lives.

101
00:03:34,120 --> 00:03:35,600
Think of a library catalog.

102
00:03:35,600 --> 00:03:38,360
The catalog card has the title, author, and shelf number.

103
00:03:38,360 --> 00:03:40,040
But the card is no, Timer, the book,

104
00:03:40,040 --> 00:03:42,200
or it just tells you where to find it.

105
00:03:42,200 --> 00:03:43,680
A virtual table works the same way.

106
00:03:43,680 --> 00:03:46,080
Dynamics 365 knows how to ask for the record

107
00:03:46,080 --> 00:03:48,640
and what feels to expose, but the outside system

108
00:03:48,640 --> 00:03:49,760
keeps the real data.

109
00:03:49,760 --> 00:03:51,560
The card is no, Tim, the book.

110
00:03:51,560 --> 00:03:53,240
So when do you see this in action?

111
00:03:53,240 --> 00:03:56,200
When you open a view of external products in a model-driven app,

112
00:03:56,200 --> 00:03:58,040
or when you look at live inventory records

113
00:03:58,040 --> 00:04:00,680
from a sales opportunity, dataverse sends a request

114
00:04:00,680 --> 00:04:02,760
to the other system, grabs the data,

115
00:04:02,760 --> 00:04:05,880
and shows it in the familiar Dynamics 365 screen.

116
00:04:05,880 --> 00:04:08,360
To the person using the app, it looks like any other table.

117
00:04:08,360 --> 00:04:10,520
They see columns in a grid, they open a form,

118
00:04:10,520 --> 00:04:12,440
and they select a record and read the fields.

119
00:04:12,440 --> 00:04:15,680
Nothing announces that the number came from a different application.

120
00:04:15,680 --> 00:04:17,240
The connection happens behind the scenes.

121
00:04:17,240 --> 00:04:19,400
But here, Tim's the important part.

122
00:04:19,400 --> 00:04:21,920
When someone views the data, it does know to me,

123
00:04:21,920 --> 00:04:23,680
silently move into dataverse.

124
00:04:23,680 --> 00:04:24,880
It stays where it belongs.

125
00:04:24,880 --> 00:04:27,200
Imagine Dynamics 365 as an office

126
00:04:27,200 --> 00:04:29,320
with a secure video screen on the wall.

127
00:04:29,320 --> 00:04:31,400
Across town, another office manages a stockroom

128
00:04:31,400 --> 00:04:33,240
and keeps the product records there.

129
00:04:33,240 --> 00:04:34,680
The video screen lets the sales team

130
00:04:34,680 --> 00:04:37,480
see what EU team says as on the stockroom shelves

131
00:04:37,480 --> 00:04:39,800
without carrying every box into the sales office.

132
00:04:39,800 --> 00:04:42,080
The stockroom remains where the work happens.

133
00:04:42,080 --> 00:04:43,280
Now, picture and account manager

134
00:04:43,280 --> 00:04:45,080
working on a large sales opportunity.

135
00:04:45,080 --> 00:04:47,120
The customer wants 500 units next month,

136
00:04:47,120 --> 00:04:49,240
and they need an answer while still on the call.

137
00:04:49,240 --> 00:04:51,360
The account manager opens a related virtual table

138
00:04:51,360 --> 00:04:53,120
called Product Availability.

139
00:04:53,120 --> 00:04:55,360
They see the item number, warehouse location available

140
00:04:55,360 --> 00:04:57,880
quantity, and expected replenishment date.

141
00:04:57,880 --> 00:04:59,680
Those details come straight from the warehouse

142
00:04:59,680 --> 00:05:02,800
or ERP system at that moment or not from last night.

143
00:05:02,800 --> 00:05:04,240
Tim's imported list.

144
00:05:04,240 --> 00:05:06,720
The account manager speaks from current data.

145
00:05:06,720 --> 00:05:08,840
Dynamics 365 brings sales and inventory

146
00:05:08,840 --> 00:05:10,240
together into one place.

147
00:05:10,240 --> 00:05:12,280
The warehouse system still decides the quantity.

148
00:05:12,280 --> 00:05:14,240
That separation matters because different systems

149
00:05:14,240 --> 00:05:15,520
handle different jobs.

150
00:05:15,520 --> 00:05:17,560
A warehouse system tracks stock movements.

151
00:05:17,560 --> 00:05:19,800
A finance app manages invoices and payments.

152
00:05:19,800 --> 00:05:22,400
The CRM app tracks conversations, opportunities,

153
00:05:22,400 --> 00:05:23,520
and service cases.

154
00:05:23,520 --> 00:05:25,960
Virtual tables let users see outside information

155
00:05:25,960 --> 00:05:28,560
without pretending every system needs to own every record.

156
00:05:28,560 --> 00:05:30,400
You might hear the term all run time.

157
00:05:30,400 --> 00:05:32,560
Ayo, that simply means the moment the app is running

158
00:05:32,560 --> 00:05:34,080
and someone asks for data.

159
00:05:34,080 --> 00:05:36,120
The virtual table does now empty to fetch everything

160
00:05:36,120 --> 00:05:37,760
once and keep it forever.

161
00:05:37,760 --> 00:05:40,640
It asks for the current record when a user opens a view,

162
00:05:40,640 --> 00:05:42,600
searches for something, or selects a row.

163
00:05:42,600 --> 00:05:44,840
So the virtual table is not a new database.

164
00:05:44,840 --> 00:05:46,480
It outtoms a dataverse table that

165
00:05:46,480 --> 00:05:49,280
presents outside records through Dynamics 365.

166
00:05:49,280 --> 00:05:51,640
Next, the totems follow that request from one click

167
00:05:51,640 --> 00:05:55,120
on the screen, out to the other system, and back again.

168
00:05:55,120 --> 00:05:59,040
Behind the scenes, provider, data source, and table.

169
00:05:59,040 --> 00:06:01,680
So what happens after someone selects a virtual table record

170
00:06:01,680 --> 00:06:04,360
in Dynamics 365, imagine the sales rep

171
00:06:04,360 --> 00:06:05,920
opens a list of products and types

172
00:06:05,920 --> 00:06:08,640
that filter out every item in a certain product group.

173
00:06:08,640 --> 00:06:11,880
Dynamics 365 can automatically just look inside dataverse

174
00:06:11,880 --> 00:06:14,160
for those rows because the rows live outside.

175
00:06:14,160 --> 00:06:15,760
Instead, dataverse sends the request

176
00:06:15,760 --> 00:06:16,800
through a data provider.

177
00:06:16,800 --> 00:06:19,200
A data provider is the translator in the setup.

178
00:06:19,200 --> 00:06:22,920
Dynamics 365 asks for data in its own format, our table name,

179
00:06:22,920 --> 00:06:25,480
columns, filters, record IDs.

180
00:06:25,480 --> 00:06:28,360
The outside system may speak a completely different language.

181
00:06:28,360 --> 00:06:30,440
The provider translates between the two sides.

182
00:06:30,440 --> 00:06:33,160
Think of it like a receptionist who speaks two languages.

183
00:06:33,160 --> 00:06:36,040
The sales rep asks for available products in English.

184
00:06:36,040 --> 00:06:37,640
The receptionist turns that question

185
00:06:37,640 --> 00:06:41,040
into the warehouse system out TMS language, sends it,

186
00:06:41,040 --> 00:06:43,400
receives the reply, and presents the answer

187
00:06:43,400 --> 00:06:45,800
in a form the sales rep can use.

188
00:06:45,800 --> 00:06:47,400
Users never see that translation.

189
00:06:47,400 --> 00:06:50,240
Behind the scenes, the provider handles the conversation.

190
00:06:50,240 --> 00:06:52,880
Dataverse includes a provider for ODATA version 4.

191
00:06:52,880 --> 00:06:56,120
ODATA is a standard way for systems to share data over the web.

192
00:06:56,120 --> 00:06:58,560
If an external service supports ODATA version 4,

193
00:06:58,560 --> 00:07:00,240
it can describe its tables and fields

194
00:07:00,240 --> 00:07:01,880
in a way dataverse understands.

195
00:07:01,880 --> 00:07:03,240
That gives you a common starting point

196
00:07:03,240 --> 00:07:05,600
instead of writing a separate connection from scratch.

197
00:07:05,600 --> 00:07:06,920
For example, an outside service

198
00:07:06,920 --> 00:07:08,800
might expose a collection called products

199
00:07:08,800 --> 00:07:10,280
with fields like product number,

200
00:07:10,280 --> 00:07:12,960
description, unit price, and available quantity.

201
00:07:12,960 --> 00:07:15,000
The ODATA provider can request those records

202
00:07:15,000 --> 00:07:16,640
and pass them back to dataverse.

203
00:07:16,640 --> 00:07:18,280
But the provider still needs to know

204
00:07:18,280 --> 00:07:20,000
where the service lives and how to reach it.

205
00:07:20,000 --> 00:07:22,440
That information sits in a data source record.

206
00:07:22,440 --> 00:07:25,480
A data source is the connection card for the outside system.

207
00:07:25,480 --> 00:07:27,520
It holds details like the service address,

208
00:07:27,520 --> 00:07:30,240
sign in credentials, and how long dataverse should wait

209
00:07:30,240 --> 00:07:32,360
before treating a request as timed out.

210
00:07:32,360 --> 00:07:34,800
Think of it as the address book entry for the service.

211
00:07:34,800 --> 00:07:36,680
The provider knows how to speak the language,

212
00:07:36,680 --> 00:07:38,680
the data source tells it which system to call

213
00:07:38,680 --> 00:07:40,240
and how to get through the front door.

214
00:07:40,240 --> 00:07:41,840
Then comes the virtual table itself.

215
00:07:41,840 --> 00:07:43,920
The virtual table gives dataverse a familiar shape

216
00:07:43,920 --> 00:07:45,280
for the outside data.

217
00:07:45,280 --> 00:07:48,200
You choose a table name, define the columns users need,

218
00:07:48,200 --> 00:07:50,280
and connect each column to the matching field

219
00:07:50,280 --> 00:07:51,480
from the external system.

220
00:07:51,480 --> 00:07:54,320
Maybe the warehouse system calls a field available quantity

221
00:07:54,320 --> 00:07:57,360
while your Dynamics 365 app calls it stock on hand.

222
00:07:57,360 --> 00:07:58,520
That automates fine.

223
00:07:58,520 --> 00:08:00,360
The mapping tells dataverse that both names

224
00:08:00,360 --> 00:08:02,560
point to the same piece of data.

225
00:08:02,560 --> 00:08:05,480
The user sees stock on hand in the Dynamics screen

226
00:08:05,480 --> 00:08:08,200
while the provider knows to request available quantity

227
00:08:08,200 --> 00:08:09,280
from the source.

228
00:08:09,280 --> 00:08:10,960
Each outside record also needs an ID

229
00:08:10,960 --> 00:08:12,440
that dataverse can recognize.

230
00:08:12,440 --> 00:08:15,040
For virtual tables, that ID needs to work as a gridau

231
00:08:15,040 --> 00:08:17,720
the long unique ID format dataverse uses.

232
00:08:17,720 --> 00:08:19,880
The provider uses that ID to connect the record

233
00:08:19,880 --> 00:08:22,160
on screen with the record in the source system.

234
00:08:22,160 --> 00:08:24,840
Without a dependable ID, dataverse can out empty

235
00:08:24,840 --> 00:08:26,720
know which exact record you selected.

236
00:08:26,720 --> 00:08:28,080
Now follow the full journey.

237
00:08:28,080 --> 00:08:29,960
A user opens a product view and filters

238
00:08:29,960 --> 00:08:31,640
for items that are in stock.

239
00:08:31,640 --> 00:08:34,600
Dataverse sees the request against the virtual table.

240
00:08:34,600 --> 00:08:36,240
The data provider reads the request,

241
00:08:36,240 --> 00:08:39,160
uses the data source details to contact the outside service,

242
00:08:39,160 --> 00:08:42,400
and translates the filter into a query that service understands.

243
00:08:42,400 --> 00:08:44,240
The source system finds the matching records

244
00:08:44,240 --> 00:08:45,320
and sends them back.

245
00:08:45,320 --> 00:08:48,440
The provider turns those results into dataverse table rows.

246
00:08:48,440 --> 00:08:51,480
Then Dynamics 365 displays the product names, prices,

247
00:08:51,480 --> 00:08:54,520
and quantities in the same sort of grid your users already know.

248
00:08:54,520 --> 00:08:56,320
The screen feels familiar because dataverse

249
00:08:56,320 --> 00:08:57,800
does the presentation work.

250
00:08:57,800 --> 00:08:59,600
The outside system does the data work.

251
00:08:59,600 --> 00:09:02,640
What if the source does now attempt support or data?

252
00:09:02,640 --> 00:09:05,000
That items where a custom data provider comes in.

253
00:09:05,000 --> 00:09:07,560
A developer can build a provider for another type of service

254
00:09:07,560 --> 00:09:10,120
or a REST API, a database connection,

255
00:09:10,120 --> 00:09:12,920
or a company system with its own data exchange format.

256
00:09:12,920 --> 00:09:15,400
The custom provider still plays translator.

257
00:09:15,400 --> 00:09:18,880
It receives a request from dataverse, contacts the outside system,

258
00:09:18,880 --> 00:09:20,920
turns the reply into dataverse records,

259
00:09:20,920 --> 00:09:22,240
and returns them to the app.

260
00:09:22,240 --> 00:09:24,320
That work takes code and careful testing

261
00:09:24,320 --> 00:09:27,000
because the provider decides how well filters, searches,

262
00:09:27,000 --> 00:09:28,440
and record lookups behave.

263
00:09:28,440 --> 00:09:30,760
A provider can also support more than reading.

264
00:09:30,760 --> 00:09:32,920
The built-in or data version for provider supports

265
00:09:32,920 --> 00:09:35,720
create, read, update, and delete actions.

266
00:09:35,720 --> 00:09:37,920
Custom providers can support those same actions

267
00:09:37,920 --> 00:09:40,960
when developers build them for the external system.

268
00:09:40,960 --> 00:09:43,240
For finance and operations virtual entities,

269
00:09:43,240 --> 00:09:45,960
dataverse can also send create, read, update,

270
00:09:45,960 --> 00:09:48,800
and delete requests straight to the finance and operations app.

271
00:09:48,800 --> 00:09:50,520
That does not mean every virtual table

272
00:09:50,520 --> 00:09:52,160
lets users edit records.

273
00:09:52,160 --> 00:09:53,880
Write actions depend on the provider

274
00:09:53,880 --> 00:09:55,880
and on what the outside system permits.

275
00:09:55,880 --> 00:09:58,480
The source system still receives the request and applies

276
00:09:58,480 --> 00:10:00,400
its own rules before it changes anything.

277
00:10:00,400 --> 00:10:03,320
So there are three building blocks behind every virtual table.

278
00:10:03,320 --> 00:10:04,880
The provider translates the request.

279
00:10:04,880 --> 00:10:06,760
The data source points to the outside service.

280
00:10:06,760 --> 00:10:10,040
The virtual table maps what users see in Dynamics 365

281
00:10:10,040 --> 00:10:12,400
to the fields and records that service returns.

282
00:10:12,400 --> 00:10:13,840
Once you see those rolled separately,

283
00:10:13,840 --> 00:10:15,600
you can also see why a virtual table

284
00:10:15,600 --> 00:10:18,280
fits some kinds of data much better than others.

285
00:10:18,280 --> 00:10:21,360
Where virtual entities fit best.

286
00:10:21,360 --> 00:10:23,840
So when does a virtual table really make sense?

287
00:10:23,840 --> 00:10:25,880
It makes sense when another business system already

288
00:10:25,880 --> 00:10:29,160
owns the data, but your people working in Dynamics 365

289
00:10:29,160 --> 00:10:31,920
need to see that data right when they're helping a customer.

290
00:10:31,920 --> 00:10:33,800
Picture a sales rep getting a quote ready.

291
00:10:33,800 --> 00:10:36,040
They need product details, current stock,

292
00:10:36,040 --> 00:10:37,640
maybe a promised delivery date,

293
00:10:37,640 --> 00:10:39,360
and the status of an earlier purchase.

294
00:10:39,360 --> 00:10:41,120
The ERP system owns all those records

295
00:10:41,120 --> 00:10:43,600
because it handles purchasing stock movement, pricing,

296
00:10:43,600 --> 00:10:44,360
and fulfillment.

297
00:10:44,360 --> 00:10:46,720
You could copy everything into data versus A.U.

298
00:10:46,720 --> 00:10:48,400
But if that copy data only exists,

299
00:10:48,400 --> 00:10:49,520
so the rep can look at it,

300
00:10:49,520 --> 00:10:51,480
you're creating extra work without changing

301
00:10:51,480 --> 00:10:53,240
who actually owns the record.

302
00:10:53,240 --> 00:10:55,520
A virtual table lets the rep work from one screen

303
00:10:55,520 --> 00:10:57,600
while the ERP keeps running the business process

304
00:10:57,600 --> 00:10:58,440
behind the scenes.

305
00:10:58,440 --> 00:10:59,560
Let's take a live product data.

306
00:10:59,560 --> 00:11:01,560
A product catalog might have thousands of items

307
00:11:01,560 --> 00:11:04,200
with descriptions, units, prices, supply details,

308
00:11:04,200 --> 00:11:05,240
and availability.

309
00:11:05,240 --> 00:11:08,240
Sales staff need enough of that information to help a customer,

310
00:11:08,240 --> 00:11:10,280
but they shouldn't have to become ERP users

311
00:11:10,280 --> 00:11:11,920
just to answer a product question.

312
00:11:11,920 --> 00:11:13,800
With a virtual table, that product data

313
00:11:13,800 --> 00:11:15,880
appears right next to accounts, opportunities,

314
00:11:15,880 --> 00:11:18,040
and quotes inside Dynamics 365.

315
00:11:18,040 --> 00:11:19,880
Inventory is another great example.

316
00:11:19,880 --> 00:11:22,560
Stock changes all day as goods arrive, orders ship,

317
00:11:22,560 --> 00:11:24,720
and warehouse teams move items around.

318
00:11:24,720 --> 00:11:27,520
When a customer asks, can you deliver this next week?

319
00:11:27,520 --> 00:11:29,080
The answer needs to come from the system,

320
00:11:29,080 --> 00:11:30,560
tracking the shelves and deliveries,

321
00:11:30,560 --> 00:11:33,480
how, not from a separate list someone copied earlier.

322
00:11:33,480 --> 00:11:35,160
Purchase status works in a similar way,

323
00:11:35,160 --> 00:11:37,040
a customer service agent might need to check

324
00:11:37,040 --> 00:11:39,080
if a replacement part has been ordered,

325
00:11:39,080 --> 00:11:40,560
whether it arrived from a supplier

326
00:11:40,560 --> 00:11:42,200
or if it's waiting for dispatch.

327
00:11:42,200 --> 00:11:44,800
That information lives in the purchasing or warehouse system,

328
00:11:44,800 --> 00:11:47,320
but the agent sees it right next to the service case.

329
00:11:47,320 --> 00:11:48,800
Finance records can work well too

330
00:11:48,800 --> 00:11:50,000
when the goal is visibility.

331
00:11:50,000 --> 00:11:52,120
A sales or service person might need to know

332
00:11:52,120 --> 00:11:55,120
if an invoice is paid, overdue, or under review

333
00:11:55,120 --> 00:11:56,400
before making a decision.

334
00:11:56,400 --> 00:11:58,760
Finance keeps responsibility for the invoice.

335
00:11:58,760 --> 00:12:02,080
Dynamics 365 just brings the status into the customer conversation.

336
00:12:02,080 --> 00:12:03,720
Here's the thing, oh you.

337
00:12:03,720 --> 00:12:05,560
People often ask for one system

338
00:12:05,560 --> 00:12:07,920
when what they really need is one place to work.

339
00:12:07,920 --> 00:12:09,280
Those are two different things.

340
00:12:09,280 --> 00:12:10,880
You can give someone a single work screen

341
00:12:10,880 --> 00:12:13,560
without cramming every business record into one database.

342
00:12:13,560 --> 00:12:16,200
Finance and operations uses this idea directly.

343
00:12:16,200 --> 00:12:19,040
Its OD entities can show up as virtual tables in Dataverse,

344
00:12:19,040 --> 00:12:21,080
so makers can build customer engagement apps

345
00:12:21,080 --> 00:12:23,000
and power platform experiences around finance

346
00:12:23,000 --> 00:12:26,280
and operations data without copying that data first.

347
00:12:26,280 --> 00:12:27,440
Depending on the setup,

348
00:12:27,440 --> 00:12:29,760
users can even create update or delete finance

349
00:12:29,760 --> 00:12:31,760
and operations records through Dataverse.

350
00:12:31,760 --> 00:12:34,920
The Finance and Operations app still applies its own business rules

351
00:12:34,920 --> 00:12:38,040
and that matters because a record does more than just hold fields.

352
00:12:38,040 --> 00:12:39,560
When someone changes a purchase order,

353
00:12:39,560 --> 00:12:42,040
adjusts stock or updates and invoice related record,

354
00:12:42,040 --> 00:12:44,400
the owning system might need to run checks and rules

355
00:12:44,400 --> 00:12:45,960
before accepting the change.

356
00:12:45,960 --> 00:12:48,400
Virtual tables keep that process in the right place.

357
00:12:48,400 --> 00:12:50,800
External marketing data can fit this pattern too.

358
00:12:50,800 --> 00:12:52,800
Maybe a marketing platform tracks email opens,

359
00:12:52,800 --> 00:12:55,040
event registrations or campaign activity

360
00:12:55,040 --> 00:12:57,800
while Dynamics 365 tracks the account manager out there

361
00:12:57,800 --> 00:12:59,760
as calls and opportunities.

362
00:12:59,760 --> 00:13:01,520
Showing a few selected marketing details

363
00:13:01,520 --> 00:13:03,840
beside a customer record gives the account manager better

364
00:13:03,840 --> 00:13:06,160
context without creating another permanent set

365
00:13:06,160 --> 00:13:08,520
of campaign records inside Dataverse.

366
00:13:08,520 --> 00:13:11,280
The same idea works with an outside product catalog.

367
00:13:11,280 --> 00:13:13,520
A company might sell products from a supplier,

368
00:13:13,520 --> 00:13:14,600
the outcomes catalog,

369
00:13:14,600 --> 00:13:17,040
where descriptions and availability change often.

370
00:13:17,040 --> 00:13:19,080
The supplier stays responsible for the catalog

371
00:13:19,080 --> 00:13:21,800
while your Dynamics 365 users browse current information

372
00:13:21,800 --> 00:13:22,560
during sales work,

373
00:13:22,560 --> 00:13:24,200
so ask yourself a simple question.

374
00:13:24,200 --> 00:13:27,680
Does Dynamics 365 need to run the life cycle of this record?

375
00:13:27,680 --> 00:13:30,880
Or do users just need to see and sometimes act on the record

376
00:13:30,880 --> 00:13:31,720
while they work?

377
00:13:31,720 --> 00:13:33,480
When the source system owns the record

378
00:13:33,480 --> 00:13:35,600
and a live view helps people do their jobs,

379
00:13:35,600 --> 00:13:37,280
a virtual table fits really well.

380
00:13:37,280 --> 00:13:38,760
But keep in mind, oh,

381
00:13:38,760 --> 00:13:40,800
a table that looks normal on screen

382
00:13:40,800 --> 00:13:43,000
doesn't automatically support every feature

383
00:13:43,000 --> 00:13:45,120
of a normal Dataverse table.

384
00:13:45,120 --> 00:13:47,120
Limits security and performance.

385
00:13:47,120 --> 00:13:49,880
A virtual table can look like a normal Dataverse table on screen,

386
00:13:49,880 --> 00:13:51,600
but don't assume it works like one.

387
00:13:51,600 --> 00:13:53,360
The data lives outside Dataverse

388
00:13:53,360 --> 00:13:55,880
and that changes what Dynamics 365 can do with it.

389
00:13:55,880 --> 00:13:58,200
Before you build a process around virtual Data,

390
00:13:58,200 --> 00:13:59,800
check whether the feature you need works

391
00:13:59,800 --> 00:14:01,640
with the provider and the outside system.

392
00:14:01,640 --> 00:14:03,800
Take writing Data back to the source system.

393
00:14:03,800 --> 00:14:05,640
Many older virtual entity setups

394
00:14:05,640 --> 00:14:07,280
only supported reading AU users

395
00:14:07,280 --> 00:14:09,200
could open a record and see current information,

396
00:14:09,200 --> 00:14:11,720
but they couldn't edit it from Dynamics 365.

397
00:14:11,720 --> 00:14:13,800
Today, the built-in OData V4 provider

398
00:14:13,800 --> 00:14:16,800
can support Create, Read, Update and Delete actions

399
00:14:16,800 --> 00:14:18,960
and custom providers can support them too.

400
00:14:18,960 --> 00:14:21,640
Still, that support doesn't appear automatically.

401
00:14:21,640 --> 00:14:23,240
The provider has to understand the action

402
00:14:23,240 --> 00:14:25,000
the outside system has to allow it

403
00:14:25,000 --> 00:14:27,520
and the user needs permission in that outside system.

404
00:14:27,520 --> 00:14:29,000
If any one of those pieces doesn't work

405
00:14:29,000 --> 00:14:31,760
and edit can fail, even when the Dynamics 365 form

406
00:14:31,760 --> 00:14:32,880
shows an edit button.

407
00:14:32,880 --> 00:14:35,560
Some Dataverse features also need stored records.

408
00:14:35,560 --> 00:14:37,680
Virtual tables don't support Dataverse auditing,

409
00:14:37,680 --> 00:14:39,760
so Dataverse won't keep its own audit history

410
00:14:39,760 --> 00:14:40,920
for changes to those records.

411
00:14:40,920 --> 00:14:42,960
If you need a clear record of who changed the value

412
00:14:42,960 --> 00:14:45,400
and when, the outside system must track that

413
00:14:45,400 --> 00:14:48,480
or you need to bring the data into a standard Dataverse table.

414
00:14:48,480 --> 00:14:51,200
Dataverse Search doesn't support Virtual tables either

415
00:14:51,200 --> 00:14:53,280
and neither do charts and dashboards.

416
00:14:53,280 --> 00:14:55,480
You also can't cache Virtual Table records

417
00:14:55,480 --> 00:14:57,040
for offline work older field engineer

418
00:14:57,040 --> 00:14:59,040
using a mobile device without a connection,

419
00:14:59,040 --> 00:15:01,280
can't rely on Virtual Data being available.

420
00:15:01,280 --> 00:15:02,880
Calculated columns and roll-up columns

421
00:15:02,880 --> 00:15:04,360
don't work on Virtual tables either.

422
00:15:04,360 --> 00:15:07,000
Any calculation needs to happen in the outside system

423
00:15:07,000 --> 00:15:09,400
or the Data provider needs to return the finished value.

424
00:15:09,400 --> 00:15:11,640
For example, if you need a total stock value

425
00:15:11,640 --> 00:15:13,160
based on quantity and price,

426
00:15:13,160 --> 00:15:15,280
calculated whether product data lives

427
00:15:15,280 --> 00:15:18,000
rather than expecting Dataverse to build the number later.

428
00:15:18,000 --> 00:15:20,080
Security needs the same careful thought.

429
00:15:20,080 --> 00:15:22,520
Virtual tables are organization-owned tables.

430
00:15:22,520 --> 00:15:25,080
Dataverse can turn access to the table on or off

431
00:15:25,080 --> 00:15:26,400
through security roles,

432
00:15:26,400 --> 00:15:28,680
but it doesn't apply the usual user-owned

433
00:15:28,680 --> 00:15:30,920
row security model or field-level security

434
00:15:30,920 --> 00:15:32,360
to the external rows.

435
00:15:32,360 --> 00:15:34,040
In plain English, Dataverse controls

436
00:15:34,040 --> 00:15:35,520
who gets through the front door.

437
00:15:35,520 --> 00:15:37,720
The outside system decides which records and fields

438
00:15:37,720 --> 00:15:39,360
they see once they're inside.

439
00:15:39,360 --> 00:15:41,360
For Finance and Operations Virtual tables,

440
00:15:41,360 --> 00:15:43,680
Dataverse passes the calling user's identity

441
00:15:43,680 --> 00:15:45,040
to Finance and Operations,

442
00:15:45,040 --> 00:15:47,200
which then checks that user's permissions

443
00:15:47,200 --> 00:15:49,920
and row-level rules before returning the data.

444
00:15:49,920 --> 00:15:51,560
That keeps the Finance or Operations app

445
00:15:51,560 --> 00:15:53,280
in control of its own records.

446
00:15:53,280 --> 00:15:55,760
Other Data providers may handle security differently.

447
00:15:55,760 --> 00:15:58,120
Before you expose customer, Finance or stock data

448
00:15:58,120 --> 00:16:00,520
through a Virtual Table, ask a direct question.

449
00:16:00,520 --> 00:16:02,040
When a user opens this record,

450
00:16:02,040 --> 00:16:03,920
which system checks their permission?

451
00:16:03,920 --> 00:16:05,680
You need a clear answer, not a guess.

452
00:16:05,680 --> 00:16:08,080
Performance also depends on the outside system.

453
00:16:08,080 --> 00:16:10,320
A normal Dataverse table reads from DataStore

454
00:16:10,320 --> 00:16:11,560
to close to the app.

455
00:16:11,560 --> 00:16:14,080
A Virtual Table sends a request to another service,

456
00:16:14,080 --> 00:16:15,920
waits for that service to process it,

457
00:16:15,920 --> 00:16:17,200
and waits for the reply.

458
00:16:17,200 --> 00:16:18,640
A fast source feels natural.

459
00:16:18,640 --> 00:16:21,440
A slow source turns a simple view into a long wait.

460
00:16:21,440 --> 00:16:23,960
That delay can grow when a view asks for many rows.

461
00:16:23,960 --> 00:16:26,560
Includes lots of columns or uses look-up columns

462
00:16:26,560 --> 00:16:27,840
that need extra reads.

463
00:16:27,840 --> 00:16:29,280
Keep Virtual Views focused.

464
00:16:29,280 --> 00:16:31,080
Return the fields people truly need,

465
00:16:31,080 --> 00:16:32,880
and avoid treating a Virtual Table

466
00:16:32,880 --> 00:16:35,720
as a place to browse thousands of records without a filter.

467
00:16:35,720 --> 00:16:37,600
For Finance and Operations connections,

468
00:16:37,600 --> 00:16:40,000
Microsoft recommends keeping Dataverse and Finance

469
00:16:40,000 --> 00:16:43,480
and Operations in the same Azure region to cut down on delay.

470
00:16:43,480 --> 00:16:46,080
The external data also needs a Guide primary key.

471
00:16:46,080 --> 00:16:49,280
A Guide is the long, unique record ID the Dataverse uses.

472
00:16:49,280 --> 00:16:50,560
Each external row needs one,

473
00:16:50,560 --> 00:16:52,560
so Dataverse can tell one product, invoice,

474
00:16:52,560 --> 00:16:54,640
or customer record apart from every other record.

475
00:16:54,640 --> 00:16:57,600
If the source system can't provide a dependable Guide,

476
00:16:57,600 --> 00:16:59,240
this Virtual Table model won't work

477
00:16:59,240 --> 00:17:01,080
without extra effort in the provider.

478
00:17:01,080 --> 00:17:04,160
One more choice becomes permanent when you create the table.

479
00:17:04,160 --> 00:17:06,160
You can't turn a Virtual Table into

480
00:17:06,160 --> 00:17:08,080
a standard Dataverse Table later,

481
00:17:08,080 --> 00:17:10,840
and you can't take a standard Table and switch it into a Virtual One.

482
00:17:10,840 --> 00:17:12,680
Choose the Table Type based on how people

483
00:17:12,680 --> 00:17:13,920
actually need to use the data,

484
00:17:13,920 --> 00:17:16,320
not just what looks easiest during setup.

485
00:17:16,320 --> 00:17:18,160
If you need offline use, audit history,

486
00:17:18,160 --> 00:17:20,000
Dataverse search, charts, dashboards,

487
00:17:20,000 --> 00:17:21,560
or Dataverse manage calculations,

488
00:17:21,560 --> 00:17:23,440
a local Dataverse Table with a plan sink

489
00:17:23,440 --> 00:17:24,960
may suit the job better.

490
00:17:24,960 --> 00:17:26,640
A Virtual Table gives you live access,

491
00:17:26,640 --> 00:17:28,240
but it also brings the outside systems

492
00:17:28,240 --> 00:17:30,400
limits straight into your app.

493
00:17:30,400 --> 00:17:33,880
Choosing the right approach, window, or local copy.

494
00:17:33,880 --> 00:17:35,760
So how do you choose between a Virtual Table

495
00:17:35,760 --> 00:17:37,320
and a standard Table with sink?

496
00:17:37,320 --> 00:17:38,360
Start with two questions.

497
00:17:38,360 --> 00:17:39,680
First, who owns the Data?

498
00:17:39,680 --> 00:17:42,400
Second, do your users always need the latest version

499
00:17:42,400 --> 00:17:43,680
when they open a record?

500
00:17:43,680 --> 00:17:45,480
If another system owns the Data and your team

501
00:17:45,480 --> 00:17:48,160
just needs a live view while working in Dynamics 365,

502
00:17:48,160 --> 00:17:49,160
use a Virtual Table.

503
00:17:49,160 --> 00:17:50,840
Think of it as a window, you see through it,

504
00:17:50,840 --> 00:17:52,040
but nothing gets copied.

505
00:17:52,040 --> 00:17:54,400
If you need offline access, detailed auditing,

506
00:17:54,400 --> 00:17:56,880
custom reporting, or any Dataverse only feature,

507
00:17:56,880 --> 00:17:58,600
choose a standard Table with sink.

508
00:17:58,600 --> 00:17:59,680
That's your local copy.

509
00:17:59,680 --> 00:18:01,960
The data is stored right inside Dataverse.

510
00:18:01,960 --> 00:18:05,480
Virtual Entities connect Dynamics 365 to Data that lives elsewhere

511
00:18:05,480 --> 00:18:06,880
without creating a second copy.

512
00:18:06,880 --> 00:18:07,720
That's the magic of it.

513
00:18:07,720 --> 00:18:09,840
Subscribe on your favorite podcast platform

514
00:18:09,840 --> 00:18:11,000
and share this knowledge nugget

515
00:18:11,000 --> 00:18:14,000
with someone connecting Dynamics 365 to another business system.