LinkedIn + Dynamics 365: The Architecture of Modern Selling

1
00:00:00,000 --> 00:00:04,000
Your CRM contains records, your actual business happens in relationships.

2
00:00:04,000 --> 00:00:09,800
Linkedin holds the graph, Dynamics 365 holds the process, neither alone tells you what's really happening.

3
00:00:09,800 --> 00:00:14,500
Most organizations treat these as separate systems, they're not, they're two halves of the same problem.

4
00:00:14,500 --> 00:00:18,100
This episode is about the architecture that connects them, not as a feature,

5
00:00:18,100 --> 00:00:21,200
but as a structural shift in how modern sales actually works.

6
00:00:21,200 --> 00:00:26,100
We'll move from the old model of manual data entry to the new model of autonomous relationship intelligence.

7
00:00:26,100 --> 00:00:27,900
Why your CRM is blind?

8
00:00:27,900 --> 00:00:32,300
Your Dynamics 365 sales environment holds what you know about customers.

9
00:00:32,300 --> 00:00:34,500
It doesn't hold what's true about them. There's a difference.

10
00:00:34,500 --> 00:00:36,100
What you know is what you've typed in.

11
00:00:36,100 --> 00:00:39,100
A contact record shows a job title, a company, and a last activity date.

12
00:00:39,100 --> 00:00:41,300
But what's true is what's happening right now in the market.

13
00:00:41,300 --> 00:00:45,400
That prospect just got promoted. They changed jobs. They're engaging with your competitor.

14
00:00:45,400 --> 00:00:49,500
None of that is in your system when it happens. It's locked in someone's browser on LinkedIn.

15
00:00:49,500 --> 00:00:54,100
The gap between what your CRM knows and what actually matters is where deals slip away.

16
00:00:54,100 --> 00:00:56,200
That gap is the cost of your architecture.

17
00:00:56,200 --> 00:00:59,500
LinkedIn has that data in real time, but it's locked behind a browser.

18
00:00:59,500 --> 00:01:02,600
Getting it into your CRM requires manual work, third party tools,

19
00:01:02,600 --> 00:01:04,600
or APIs that weren't designed for scale.

20
00:01:04,600 --> 00:01:09,600
Your sales team compensates by living on LinkedIn, then manually logging back into Dynamics.

21
00:01:09,600 --> 00:01:12,100
Two systems, two versions of truth, double work.

22
00:01:12,100 --> 00:01:15,700
The cost isn't just time. It's decision-making based on stale data.

23
00:01:15,700 --> 00:01:18,100
A contact record hasn't been updated in two months.

24
00:01:18,100 --> 00:01:20,300
The seller doesn't know the relationship has cooled.

25
00:01:20,300 --> 00:01:22,300
They don't know the decision maker was replaced.

26
00:01:22,300 --> 00:01:24,100
They don't know the company just had layoffs.

27
00:01:24,100 --> 00:01:27,300
So they send an email based on assumptions that are no longer true.

28
00:01:27,300 --> 00:01:31,000
The message lands wrong. The response never comes. It's missed signals.

29
00:01:31,000 --> 00:01:34,300
It's relationships that fade because nobody saw the change happening.

30
00:01:34,300 --> 00:01:38,700
It's forecast misses because you're looking at opportunity stage instead of relationship health.

31
00:01:38,700 --> 00:01:42,100
It's deals that slip into the lost category when they could have been saved

32
00:01:42,100 --> 00:01:45,100
with the right intervention at the right time. This is the blind spot.

33
00:01:45,100 --> 00:01:49,600
Your CRM is a database of records, but your actual business is a network of relationships.

34
00:01:49,600 --> 00:01:52,700
Those relationships exist on LinkedIn. They exist in email threads.

35
00:01:52,700 --> 00:01:56,100
They exist in meeting transcripts, but your CRM doesn't see them.

36
00:01:56,100 --> 00:02:00,400
Your CRM only sees what a human thought to log in, which is almost never the full picture.

37
00:02:00,400 --> 00:02:05,100
The problem isn't new. Organizations have been struggling with this disconnect for years.

38
00:02:05,100 --> 00:02:07,600
What's changed is that the tools to fix it now exist.

39
00:02:07,600 --> 00:02:12,300
LinkedIn's APIs are mature. Dynamics 365 has relationship intelligence built in.

40
00:02:12,300 --> 00:02:16,200
Power automate can orchestrate the flow. Co-pilot can synthesize the signals.

41
00:02:16,200 --> 00:02:21,000
Agents can operate autonomously, but they only work if you rethink how you architect the connection.

42
00:02:21,000 --> 00:02:24,600
It's not about bolting LinkedIn onto Dynamics 365 as a feature.

43
00:02:24,600 --> 00:02:28,600
It's about designing a system where the two are structural halves of the same hole.

44
00:02:28,600 --> 00:02:31,200
One side holds the process, the other side holds the graph.

45
00:02:31,200 --> 00:02:33,500
Together they tell you what's actually happening.

46
00:02:33,500 --> 00:02:36,300
That requires understanding the disconnects that exist today

47
00:02:36,300 --> 00:02:40,000
and why they persist even when the technology to fix them is available.

48
00:02:40,000 --> 00:02:41,400
The three disconnects.

49
00:02:41,400 --> 00:02:43,700
The blindness we just described isn't one problem.

50
00:02:43,700 --> 00:02:46,000
It's three problems stacked on top of each other.

51
00:02:46,000 --> 00:02:49,600
Each one creates friction on its own, but together they create a system

52
00:02:49,600 --> 00:02:52,000
that actively resists integration.

53
00:02:52,000 --> 00:02:54,000
The first is the data disconnect.

54
00:02:54,000 --> 00:02:59,800
LinkedIn's API exposes relationship signals like job changes, engagement metrics and mutual connections.

55
00:02:59,800 --> 00:03:04,200
Dynamics 365 stores customer records with names, titles and last activity dates.

56
00:03:04,200 --> 00:03:07,700
These are two different data models describing the exact same relationship

57
00:03:07,700 --> 00:03:11,300
but they don't automatically sync because there is no native bridge between them.

58
00:03:11,300 --> 00:03:13,000
What happens next is predictable.

59
00:03:13,000 --> 00:03:16,400
Sales teams either build the bridge manually or they use third party tools

60
00:03:16,400 --> 00:03:19,400
that operate in a gray area between approved and unsupported.

61
00:03:19,400 --> 00:03:20,800
The manual approach is slow.

62
00:03:20,800 --> 00:03:26,200
A seller finds a prospect on LinkedIn, notes the info, switches to Dynamics 365 and types it in

63
00:03:26,200 --> 00:03:28,000
or worse they just forget to do it.

64
00:03:28,000 --> 00:03:30,200
The third party approach works until it doesn't.

65
00:03:30,200 --> 00:03:33,800
LinkedIn might change an endpoint or the tool gets its access revoked

66
00:03:33,800 --> 00:03:35,800
or the vendor simply goes out of business.

67
00:03:35,800 --> 00:03:37,800
Either way the data lives in two places.

68
00:03:37,800 --> 00:03:41,000
Neither is the source of truth and both are slowly degrading.

69
00:03:41,000 --> 00:03:43,800
The second is the process disconnect.

70
00:03:43,800 --> 00:03:45,600
This is where the real damage happens.

71
00:03:45,600 --> 00:03:48,200
Let's say a prospect on LinkedIn just got promoted.

72
00:03:48,200 --> 00:03:51,800
This is information that should trigger action inside your organization immediately.

73
00:03:51,800 --> 00:03:55,600
The opportunity assigned to one seller should maybe be rerouted to another person

74
00:03:55,600 --> 00:03:58,000
who has a relationship with the new decision maker.

75
00:03:58,000 --> 00:04:00,600
The sales strategy for that account needs to shift

76
00:04:00,600 --> 00:04:02,600
and the competitive positioning should adapt.

77
00:04:02,600 --> 00:04:05,200
Someone should flag it as a re-engagement opportunity right away.

78
00:04:05,200 --> 00:04:07,000
But none of that happens automatically.

79
00:04:07,000 --> 00:04:11,200
There is no process that says when a contacts role changes on LinkedIn, here is what we do.

80
00:04:11,200 --> 00:04:14,000
The information exists on the profile if someone happens to look at it

81
00:04:14,000 --> 00:04:15,800
but your CRM is blind to the change.

82
00:04:15,800 --> 00:04:18,600
Your opportunity record sits in the same stage it was in last month

83
00:04:18,600 --> 00:04:20,600
because nobody knows the landscape has shifted.

84
00:04:20,600 --> 00:04:24,400
The organization keeps executing the old strategy against a new reality

85
00:04:24,400 --> 00:04:26,600
and the deal slips away.

86
00:04:26,600 --> 00:04:29,000
The third is the intelligence disconnect.

87
00:04:29,000 --> 00:04:33,600
Your CRM calculates opportunity probability based on deal size, sales cycle stage,

88
00:04:33,600 --> 00:04:35,200
and seller activity.

89
00:04:35,200 --> 00:04:37,800
That is a useful signal but it is not a complete picture.

90
00:04:37,800 --> 00:04:40,800
LinkedIn calculates something different called relationship strength.

91
00:04:40,800 --> 00:04:44,200
It looks at engagement patterns, mutual connections and message activity.

92
00:04:44,200 --> 00:04:48,000
These are independent calculations of value happening in separate systems

93
00:04:48,000 --> 00:04:49,400
that never talk to each other.

94
00:04:49,400 --> 00:04:50,400
Here is the problem.

95
00:04:50,400 --> 00:04:53,400
Your CRM's probability calculation should be informed

96
00:04:53,400 --> 00:04:55,600
by LinkedIn's relationship strength assessment.

97
00:04:55,600 --> 00:04:59,400
A $500,000 opportunity with a weak relationship has different odds

98
00:04:59,400 --> 00:05:02,000
than one with deep connections across the buying committee.

99
00:05:02,000 --> 00:05:03,800
But your CRM doesn't know the difference.

100
00:05:03,800 --> 00:05:05,800
LinkedIn knows the relationship strength

101
00:05:05,800 --> 00:05:07,600
but it doesn't know about the opportunity.

102
00:05:07,600 --> 00:05:09,600
You are forecasting with half the data

103
00:05:09,600 --> 00:05:11,200
these three gaps compound.

104
00:05:11,200 --> 00:05:14,600
A missed signal becomes a missed re-engagement opportunity

105
00:05:14,600 --> 00:05:16,200
which then becomes a lost deal.

106
00:05:16,200 --> 00:05:18,000
A lost deal leads to a forecast miss

107
00:05:18,000 --> 00:05:20,400
and a forecast miss leads to a failed quarter.

108
00:05:20,400 --> 00:05:21,800
The cost is exponential.

109
00:05:21,800 --> 00:05:25,400
The old solution was to treat sales navigator as a separate tool.

110
00:05:25,400 --> 00:05:27,000
Sellers would use it for research

111
00:05:27,000 --> 00:05:30,200
and then manually log their findings back into Dynamics 365.

112
00:05:30,200 --> 00:05:32,200
It was better than nothing but it wasn't good enough.

113
00:05:32,200 --> 00:05:35,000
It still required manual work and created two versions of the truth.

114
00:05:35,000 --> 00:05:38,200
Most importantly, it didn't trigger an organizational response.

115
00:05:38,200 --> 00:05:39,800
The new solution is architectural.

116
00:05:39,800 --> 00:05:43,600
LinkedIn data flows into Dynamics 365 as a continuous stream.

117
00:05:43,600 --> 00:05:45,000
It isn't a separate source of truth

118
00:05:45,000 --> 00:05:47,600
but a live signal layer that feeds into the CRM.

119
00:05:47,600 --> 00:05:51,200
Relationship health becomes a native capability instead of a bolt-on.

120
00:05:51,200 --> 00:05:53,800
Process triggers happen based on LinkedIn changes

121
00:05:53,800 --> 00:05:56,200
not based on what a seller remembered to log in.

122
00:05:56,200 --> 00:06:00,000
Understanding these three disconnects is the foundation for redesigning the system.

123
00:06:00,000 --> 00:06:03,200
The architecture that fixes them is what we are building toward.

124
00:06:03,200 --> 00:06:05,600
LinkedIn API is what's actually available

125
00:06:05,600 --> 00:06:06,800
so we know the problem.

126
00:06:06,800 --> 00:06:08,200
The architecture is broken.

127
00:06:08,200 --> 00:06:11,400
The question becomes, what are you actually working with to fix it?

128
00:06:11,400 --> 00:06:14,400
LinkedIn publishes APIs and it is important to state this upfront

129
00:06:14,400 --> 00:06:16,400
because the assumption most people have is wrong.

130
00:06:16,400 --> 00:06:18,400
They think LinkedIn is a closed platform

131
00:06:18,400 --> 00:06:19,800
where everything is locked away.

132
00:06:19,800 --> 00:06:20,600
It isn't.

133
00:06:20,600 --> 00:06:22,000
But it is also not an open playground

134
00:06:22,000 --> 00:06:24,000
where everyone gets equal access to everything.

135
00:06:24,000 --> 00:06:25,400
Access is tiered.

136
00:06:25,400 --> 00:06:27,600
That matters more than most teams realize

137
00:06:27,600 --> 00:06:29,400
when they are planning an integration.

138
00:06:29,400 --> 00:06:31,800
At the bottom tier you have consumer APIs.

139
00:06:31,800 --> 00:06:33,600
These are available to basically anyone

140
00:06:33,600 --> 00:06:36,400
for things like sign in with LinkedIn or basic profile sharing.

141
00:06:36,400 --> 00:06:39,200
These work for consumer applications and are well documented

142
00:06:39,200 --> 00:06:41,800
but they are mostly useless for what you are trying to do.

143
00:06:41,800 --> 00:06:43,200
You can get someone's name and headline

144
00:06:43,200 --> 00:06:45,800
but you cannot get engagement signals or job change history.

145
00:06:45,800 --> 00:06:48,800
You can't get the insights that would actually inform your sales strategy.

146
00:06:48,800 --> 00:06:50,400
Above that sits partner APIs.

147
00:06:50,400 --> 00:06:52,800
This includes sales navigator, recruiter,

148
00:06:52,800 --> 00:06:54,400
and the marketing developer platform.

149
00:06:54,400 --> 00:06:55,200
These are restricted.

150
00:06:55,200 --> 00:06:56,600
You don't just sign up and get access.

151
00:06:56,600 --> 00:06:58,000
You go through an approval process

152
00:06:58,000 --> 00:07:00,000
where LinkedIn reviews what you are building.

153
00:07:00,000 --> 00:07:03,200
They evaluate whether it aligns with how they want their platform used.

154
00:07:03,200 --> 00:07:05,000
If it does, they grant you access.

155
00:07:05,000 --> 00:07:06,800
If it doesn't, you're out of luck.

156
00:07:06,800 --> 00:07:09,800
Then there is a tier that most organizations never interact with.

157
00:07:09,800 --> 00:07:11,400
Compliance APIs.

158
00:07:11,400 --> 00:07:14,400
These exist for regulated industries like financial services,

159
00:07:14,400 --> 00:07:15,800
healthcare, and legal.

160
00:07:15,800 --> 00:07:18,600
They have additional restrictions and require formal partnerships.

161
00:07:18,600 --> 00:07:21,800
They are designed for scenarios where the data handling requirements

162
00:07:21,800 --> 00:07:24,800
are so strict that you need LinkedIn's direct involvement.

163
00:07:24,800 --> 00:07:28,200
Here is the practical reality that most organizations figure out

164
00:07:28,200 --> 00:07:30,400
only after they have spent months building something.

165
00:07:30,400 --> 00:07:33,400
You probably cannot build a custom direct integration

166
00:07:33,400 --> 00:07:35,000
against LinkedIn's core data.

167
00:07:35,000 --> 00:07:36,800
It isn't because you aren't smart enough.

168
00:07:36,800 --> 00:07:39,800
It's because LinkedIn controls access to protect the professional graph.

169
00:07:39,800 --> 00:07:42,400
They build sales navigator and recruiter for a reason.

170
00:07:42,400 --> 00:07:44,000
Those products are the official channels

171
00:07:44,000 --> 00:07:46,400
and going through them is the only realistic path.

172
00:07:46,400 --> 00:07:48,400
This is where rate limits enter the conversation.

173
00:07:48,400 --> 00:07:50,800
LinkedIn does not publish its quotas publicly.

174
00:07:50,800 --> 00:07:52,800
You find out what your limits are by building an app

175
00:07:52,800 --> 00:07:55,800
going through the approval process and then hitting the wall.

176
00:07:55,800 --> 00:07:59,000
Your app gets a specific quota and so does each member using it.

177
00:07:59,000 --> 00:08:01,000
If you make a request that exceeds that quota,

178
00:08:01,000 --> 00:08:03,200
you get an HTTP 429 error.

179
00:08:03,200 --> 00:08:04,800
Too many requests that isn't an error.

180
00:08:04,800 --> 00:08:07,000
It's a signal. It's LinkedIn's way of saying stop.

181
00:08:07,000 --> 00:08:08,200
You are done for today.

182
00:08:08,200 --> 00:08:10,800
The 429 response includes a header that tells you exactly

183
00:08:10,800 --> 00:08:12,000
when you can try again.

184
00:08:12,000 --> 00:08:14,800
If you ignore it and hammer the API anyway,

185
00:08:14,800 --> 00:08:17,800
the throttling gets more aggressive and your requests slow down.

186
00:08:17,800 --> 00:08:20,000
This is by design. It isn't a bug. It is a feature.

187
00:08:20,000 --> 00:08:23,200
It is how LinkedIn prevents one organization's integration

188
00:08:23,200 --> 00:08:25,200
from degrading the platform for everyone else.

189
00:08:25,200 --> 00:08:27,000
The quotas themselves aren't arbitrary.

190
00:08:27,000 --> 00:08:30,000
They are calculated to allow reasonable usage while preventing abuse.

191
00:08:30,000 --> 00:08:32,400
A sales team of 50 people using sales navigator

192
00:08:32,400 --> 00:08:35,400
should be able to sync leads into Dynamics 365 daily

193
00:08:35,400 --> 00:08:36,600
without hitting limits.

194
00:08:36,600 --> 00:08:39,000
An organization trying to scrape all of LinkedIn's data

195
00:08:39,000 --> 00:08:40,400
would hit the limits immediately.

196
00:08:40,400 --> 00:08:41,400
That is the point.

197
00:08:41,400 --> 00:08:44,000
The authentication layer is OAuth 2.0.

198
00:08:44,000 --> 00:08:46,200
Your request specific permissions called scopes.

199
00:08:46,200 --> 00:08:48,400
You might say, "I need to read profile data"

200
00:08:48,400 --> 00:08:50,600
or "I need to write to activity history".

201
00:08:50,600 --> 00:08:53,200
LinkedIn approves only the scopes you actually need.

202
00:08:53,200 --> 00:08:56,400
If you request too much, your app gets rejected during review.

203
00:08:56,400 --> 00:08:57,600
It is a deliberate constraint

204
00:08:57,600 --> 00:08:59,600
that prevents over-privileged integrations.

205
00:08:59,600 --> 00:09:02,400
What this all means is that you are not starting from a blank slate

206
00:09:02,400 --> 00:09:03,800
when you design an integration.

207
00:09:03,800 --> 00:09:05,600
You are starting from within boundaries.

208
00:09:05,600 --> 00:09:07,200
Those boundaries are there for reasons.

209
00:09:07,200 --> 00:09:09,400
They protect the network, they protect member privacy

210
00:09:09,400 --> 00:09:11,200
and they protect the integrity of the data.

211
00:09:11,200 --> 00:09:12,400
The unrestricted path,

212
00:09:12,400 --> 00:09:15,000
where you could build whatever you want and pull whatever data you want,

213
00:09:15,000 --> 00:09:16,200
does not exist.

214
00:09:16,200 --> 00:09:18,800
For the purposes of your architecture, that is actually good.

215
00:09:18,800 --> 00:09:22,400
It means the path you need to follow is the one that LinkedIn has already designed.

216
00:09:22,400 --> 00:09:24,400
Sales navigator CRM sync leads sync

217
00:09:24,400 --> 00:09:26,600
and compliance APIs are not limitations.

218
00:09:26,600 --> 00:09:29,000
They are the scaffolding the platform provides.

219
00:09:29,000 --> 00:09:31,800
Sales navigator CRM sync, the APIs exist,

220
00:09:31,800 --> 00:09:33,800
the tier system is set, the constraints are clear.

221
00:09:33,800 --> 00:09:35,200
Now we need to move the data.

222
00:09:35,200 --> 00:09:38,200
For most organizations, that means sales navigator CRM sync.

223
00:09:38,200 --> 00:09:40,600
This is the official bridge, it is the sanctioned path.

224
00:09:40,600 --> 00:09:44,200
It is what LinkedIn and Microsoft build together specifically for this moment.

225
00:09:44,200 --> 00:09:47,400
Connecting sales navigator with Dynamics 365 sales.

226
00:09:47,400 --> 00:09:48,200
Here is how it works.

227
00:09:48,200 --> 00:09:49,000
The sync runs daily.

228
00:09:49,000 --> 00:09:50,600
It looks at your sales navigator account,

229
00:09:50,600 --> 00:09:53,800
identifies the leads and accounts you have marked or engaged with.

230
00:09:53,800 --> 00:09:56,000
And pushes them into Dynamics 365.

231
00:09:56,000 --> 00:09:57,600
No manual work, no custom connectors,

232
00:09:57,600 --> 00:10:01,000
no HTTP calls to undocumented endpoints, just configuration.

233
00:10:01,000 --> 00:10:03,800
The mechanics are straightforward, you enable it, you map the fields,

234
00:10:03,800 --> 00:10:05,200
the sync happens on a schedule.

235
00:10:05,200 --> 00:10:06,800
Your CRM stays current.

236
00:10:06,800 --> 00:10:10,400
But here is the problem, or at least a critical detail about how the data flows.

237
00:10:10,400 --> 00:10:13,800
For most fields, it is one directional, linked in feeds Dynamics.

238
00:10:13,800 --> 00:10:17,800
You get the contact name, title, company location, and the linked in URL.

239
00:10:17,800 --> 00:10:19,200
You also get engagement signals.

240
00:10:19,200 --> 00:10:21,200
You see if the prospect is active on LinkedIn.

241
00:10:21,200 --> 00:10:24,600
If they have looked at your profile, and how many mutual connections you share,

242
00:10:24,600 --> 00:10:26,400
all of that flows in one direction.

243
00:10:26,400 --> 00:10:27,000
However.

244
00:10:27,000 --> 00:10:29,000
And this matters for discipline in your process.

245
00:10:29,000 --> 00:10:30,800
Certain fields sync both ways.

246
00:10:30,800 --> 00:10:34,000
Lead source, lead status, custom fields you've configured.

247
00:10:34,000 --> 00:10:37,800
This means your CRM can be the system of record for qualification state.

248
00:10:37,800 --> 00:10:40,800
A seller marks someone as not qualified in Dynamics.

249
00:10:40,800 --> 00:10:43,000
And that signal syncs back to sales navigator.

250
00:10:43,000 --> 00:10:46,800
The system begins to reflect a shared truth instead of two separate databases.

251
00:10:46,800 --> 00:10:50,000
The volume constraint is where most organizations feel the pressure.

252
00:10:50,000 --> 00:10:53,600
The limit is 1000 leads and contacts per user per month,

253
00:10:53,600 --> 00:10:57,200
not per day per month, 1000, that's a hard cap when you hit it.

254
00:10:57,200 --> 00:10:59,200
You hit it, LinkedIn could allow unlimited sync.

255
00:10:59,200 --> 00:11:00,600
They could open the floodgates.

256
00:11:00,600 --> 00:11:02,400
But in reality, they do the opposite.

257
00:11:02,400 --> 00:11:05,800
They enforce the 1000 lead limit because it changes how you think about sales.

258
00:11:05,800 --> 00:11:07,000
It forces a question.

259
00:11:07,000 --> 00:11:08,400
Which leads actually matter?

260
00:11:08,400 --> 00:11:12,200
If you can only sync 1000, you stop treating LinkedIn like a database dump.

261
00:11:12,200 --> 00:11:14,000
You start treating it like a targeting system.

262
00:11:14,000 --> 00:11:15,000
You get selective.

263
00:11:15,000 --> 00:11:15,600
You focus.

264
00:11:15,600 --> 00:11:16,800
You apply judgment.

265
00:11:16,800 --> 00:11:19,400
For most sales teams of reasonable size,

266
00:11:19,400 --> 00:11:22,200
1000 leads per user per month is plenty.

267
00:11:22,200 --> 00:11:25,600
That's 40, 50 or 60 leads per day if you're aggressive.

268
00:11:25,600 --> 00:11:27,000
It's enough for active selling.

269
00:11:27,000 --> 00:11:28,800
It's not enough for passive bulk imports.

270
00:11:28,800 --> 00:11:29,600
That's the point.

271
00:11:29,600 --> 00:11:33,200
The system respects your existing Dynamics 365 security architecture.

272
00:11:33,200 --> 00:11:35,800
A seller only sees leads they have permission to see.

273
00:11:35,800 --> 00:11:39,800
If you've configured security roles so that someone can't view a particular account,

274
00:11:39,800 --> 00:11:41,600
sales navigator sync respects that.

275
00:11:41,600 --> 00:11:43,000
It doesn't bypass your governance.

276
00:11:43,000 --> 00:11:43,800
It works within it.

277
00:11:43,800 --> 00:11:45,000
The data mapping is simple.

278
00:11:45,000 --> 00:11:48,800
Names, titles, companies, locations, and LinkedIn URLs come across.

279
00:11:48,800 --> 00:11:50,000
Engagement signals come across.

280
00:11:50,000 --> 00:11:52,200
You see how active someone is on the platform.

281
00:11:52,200 --> 00:11:54,200
You see whether they viewed your profile,

282
00:11:54,200 --> 00:11:56,600
which is a signal that they've at least looked at who you are.

283
00:11:56,600 --> 00:11:58,200
You see the mutual connection count,

284
00:11:58,200 --> 00:12:00,800
which is genuinely useful for account-based selling.

285
00:12:00,800 --> 00:12:02,400
The practical benefit is immediate.

286
00:12:02,400 --> 00:12:04,200
Sellers spend less time on data entry.

287
00:12:04,200 --> 00:12:07,400
They don't have to manually transcribe LinkedIn profiles into Dynamics.

288
00:12:07,400 --> 00:12:10,000
They don't have to copy and paste job titles or company names.

289
00:12:10,000 --> 00:12:11,000
The system does it.

290
00:12:11,000 --> 00:12:12,000
That's time reclaimed.

291
00:12:12,000 --> 00:12:15,400
That's mental energy available for actual selling instead of clerical work.

292
00:12:15,400 --> 00:12:17,600
But the strategic benefit is what matters more.

293
00:12:17,600 --> 00:12:21,200
Your CRM stays current with LinkedIn activity without manual intervention.

294
00:12:21,200 --> 00:12:23,000
When a prospect engages on LinkedIn,

295
00:12:23,000 --> 00:12:24,800
that signal flows into your system.

296
00:12:24,800 --> 00:12:26,800
The engagement appears in the activity timeline.

297
00:12:26,800 --> 00:12:28,800
The relationship health calculation includes it.

298
00:12:28,800 --> 00:12:30,400
Your organization sees the signal.

299
00:12:30,400 --> 00:12:32,400
Because the signal exists in your system.

300
00:12:32,400 --> 00:12:33,600
It can trigger action.

301
00:12:33,600 --> 00:12:36,600
A workflow can notice the activity and alert the seller.

302
00:12:36,600 --> 00:12:39,600
A manager can see the engagement pattern and coach accordingly.

303
00:12:39,600 --> 00:12:40,600
This is the foundation.

304
00:12:40,600 --> 00:12:42,800
Not advanced, not fancy, but real.

305
00:12:42,800 --> 00:12:45,600
It's the bridge that closes the data disconnect.

306
00:12:45,600 --> 00:12:47,600
Power Automate and Custom Connectors.

307
00:12:47,600 --> 00:12:50,800
Sales Navigator CRM Sync solves the straightforward case.

308
00:12:50,800 --> 00:12:53,600
You want to move leads from LinkedIn into Dynamics 365

309
00:12:53,600 --> 00:12:56,000
on a daily schedule using an official integration.

310
00:12:56,000 --> 00:12:56,600
Done.

311
00:12:56,600 --> 00:12:58,200
But not every use case fits that mold.

312
00:12:58,200 --> 00:12:59,800
Sometimes you need custom logic.

313
00:12:59,800 --> 00:13:03,000
You want to enrich contact records with data that comes from LinkedIn

314
00:13:03,000 --> 00:13:04,600
but isn't part of the standard sync.

315
00:13:04,600 --> 00:13:07,800
You want to trigger actions in Dynamics when a LinkedIn profile changes.

316
00:13:07,800 --> 00:13:11,200
You want to combine LinkedIn data with information from other systems

317
00:13:11,200 --> 00:13:14,000
in ways that the out-of-the-box integration doesn't support.

318
00:13:14,000 --> 00:13:15,600
That's where Power Automate enters.

319
00:13:15,600 --> 00:13:18,400
Power Automate is fundamentally an orchestration engine.

320
00:13:18,400 --> 00:13:21,200
It can take data from one system, transform it,

321
00:13:21,200 --> 00:13:22,400
and send it somewhere else.

322
00:13:22,400 --> 00:13:24,400
It can make decisions based on conditions.

323
00:13:24,400 --> 00:13:26,400
It can run on a schedule or respond to events

324
00:13:26,400 --> 00:13:29,400
and it can call external systems, including LinkedIn.

325
00:13:29,400 --> 00:13:30,600
Through Connectors.

326
00:13:30,600 --> 00:13:33,000
There are two patterns worth understanding here.

327
00:13:33,000 --> 00:13:34,800
The first is the Custom Connector pattern.

328
00:13:34,800 --> 00:13:35,400
Here's how it works.

329
00:13:35,400 --> 00:13:36,400
You build an API.

330
00:13:36,400 --> 00:13:38,400
This API wraps LinkedIn's endpoints

331
00:13:38,400 --> 00:13:40,400
and adds your own business logic on top.

332
00:13:40,400 --> 00:13:42,800
Maybe it handles authentication in a specific way.

333
00:13:42,800 --> 00:13:45,200
Maybe it applies some filtering or transformation.

334
00:13:45,200 --> 00:13:48,400
Maybe it handles error cases that the standard API doesn't address.

335
00:13:48,400 --> 00:13:49,400
You build the API.

336
00:13:49,400 --> 00:13:50,800
Deploy it somewhere accessible.

337
00:13:50,800 --> 00:13:52,800
And then expose it as a connector and Power Automate.

338
00:13:52,800 --> 00:13:55,000
Now any flow can use that connector

339
00:13:55,000 --> 00:13:58,000
without having to know about the underlying API complexity.

340
00:13:58,000 --> 00:13:59,800
The connector abstracts it away.

341
00:13:59,800 --> 00:14:03,600
Someone building a flow doesn't need to understand OAuth or rate limits

342
00:14:03,600 --> 00:14:05,000
or endpoint paths.

343
00:14:05,000 --> 00:14:08,600
They just drag the connector into their flow, configure it, and it works.

344
00:14:08,600 --> 00:14:10,000
This is powerful because it means

345
00:14:10,000 --> 00:14:13,200
non-technical people can use sophisticated integrations

346
00:14:13,200 --> 00:14:16,000
once someone technical has built the connector.

347
00:14:16,000 --> 00:14:18,200
The second pattern is the HTTP connector pattern.

348
00:14:18,200 --> 00:14:19,400
This is more direct.

349
00:14:19,400 --> 00:14:22,800
Your flow makes raw HTTP calls to LinkedIn's API endpoints.

350
00:14:22,800 --> 00:14:24,400
You build the authentication yourself.

351
00:14:24,400 --> 00:14:26,400
You handle the response passing yourself.

352
00:14:26,400 --> 00:14:27,800
You manage rate limits yourself.

353
00:14:27,800 --> 00:14:29,200
This gives you flexibility.

354
00:14:29,200 --> 00:14:31,600
You can do anything LinkedIn's API allows.

355
00:14:31,600 --> 00:14:33,000
But it requires more engineering.

356
00:14:33,000 --> 00:14:35,400
You're building lower-level logic directly in the flow.

357
00:14:35,400 --> 00:14:37,400
Most teams start with the HTTP pattern

358
00:14:37,400 --> 00:14:39,200
because it requires less infrastructure.

359
00:14:39,200 --> 00:14:41,400
You don't need to build and maintain a separate API.

360
00:14:41,400 --> 00:14:43,400
You just write the logic in Power Automate.

361
00:14:43,400 --> 00:14:46,000
But as you scale, as you build more flows doing similar things,

362
00:14:46,000 --> 00:14:48,800
you often find that the HTTP pattern leads to duplication.

363
00:14:48,800 --> 00:14:51,000
That's when you move to the custom connector pattern.

364
00:14:51,000 --> 00:14:52,600
You extract the common logic,

365
00:14:52,600 --> 00:14:55,200
build it once as an API, expose it as a connector,

366
00:14:55,200 --> 00:14:56,600
and then all your flows can use it.

367
00:14:56,600 --> 00:14:58,400
But here's where constraints matter again.

368
00:14:58,400 --> 00:15:00,600
Power Automate flows that call external systems

369
00:15:00,600 --> 00:15:02,400
must complete within 100 seconds

370
00:15:02,400 --> 00:15:04,400
when they're used as a synchronous tool.

371
00:15:04,400 --> 00:15:05,400
100 seconds.

372
00:15:05,400 --> 00:15:06,600
That's the timeout window.

373
00:15:06,600 --> 00:15:09,200
If your flow is still running after 100 seconds,

374
00:15:09,200 --> 00:15:10,800
Power Automate terminates it.

375
00:15:10,800 --> 00:15:11,800
The flow fails.

376
00:15:11,800 --> 00:15:14,000
The tool that called the flow doesn't get a response.

377
00:15:14,000 --> 00:15:16,800
This constraint is critical when agents are involved.

378
00:15:16,800 --> 00:15:19,400
An agent can use a Power Automate flow as a tool.

379
00:15:19,400 --> 00:15:21,600
The agent makes a request, waits for the response,

380
00:15:21,600 --> 00:15:23,400
and then uses that response in its reasoning.

381
00:15:23,400 --> 00:15:26,000
But the agent is also operating within a time budget.

382
00:15:26,000 --> 00:15:29,400
If the flow takes 110 seconds, the agent requests times out.

383
00:15:29,400 --> 00:15:30,400
The whole thing falls apart,

384
00:15:30,400 --> 00:15:32,400
so synchronous flow design becomes a discipline.

385
00:15:32,400 --> 00:15:33,400
You keep the flow fast.

386
00:15:33,400 --> 00:15:35,000
You make the LinkedIn API call.

387
00:15:35,000 --> 00:15:35,800
You get the response.

388
00:15:35,800 --> 00:15:38,600
You return it immediately if you need to do something slow.

389
00:15:38,600 --> 00:15:40,600
A complex database transformation,

390
00:15:40,600 --> 00:15:42,000
a long running calculation,

391
00:15:42,000 --> 00:15:44,800
multiple sequential API calls, you decouple it.

392
00:15:44,800 --> 00:15:46,480
The synchronous part accepts the request

393
00:15:46,480 --> 00:15:47,800
and queues it for processing.

394
00:15:47,800 --> 00:15:49,600
It returns immediately with a tracking ID.

395
00:15:49,600 --> 00:15:51,600
The asynchronous part, running separately,

396
00:15:51,600 --> 00:15:54,200
does the actual work in the background and stores the result.

397
00:15:54,200 --> 00:15:56,200
This adds complexity to your architecture.

398
00:15:56,200 --> 00:15:59,400
But its necessary complexity is the reality of building it scale.

399
00:15:59,400 --> 00:16:01,400
Batching helps manage API calls.

400
00:16:01,400 --> 00:16:04,000
Instead of updating one contact at a time in a loop,

401
00:16:04,000 --> 00:16:06,800
you batch 100 contacts into a single request.

402
00:16:06,800 --> 00:16:09,800
This counts as one call against your quota instead of 100 calls.

403
00:16:09,800 --> 00:16:11,600
It's dramatically more efficient.

404
00:16:11,600 --> 00:16:14,200
Data loss prevention policies deserve mention here.

405
00:16:14,200 --> 00:16:17,600
DLP policies restrict how data can flow through connectors.

406
00:16:17,600 --> 00:16:20,200
You configure a policy that says HTTP connectors

407
00:16:20,200 --> 00:16:23,000
can't be used with sensitive LinkedIn data.

408
00:16:23,000 --> 00:16:27,000
You block export of contact lists to unsanctioned external services.

409
00:16:27,000 --> 00:16:28,400
These policies prevent leakage.

410
00:16:28,400 --> 00:16:31,200
They prevent a flow from accidentally sending prospect data

411
00:16:31,200 --> 00:16:32,400
to the wrong place.

412
00:16:32,400 --> 00:16:34,200
And then there's the governance question.

413
00:16:34,200 --> 00:16:37,200
Using scrapers or unauthorized APIs to pull LinkedIn data

414
00:16:37,200 --> 00:16:38,600
violates their terms.

415
00:16:38,600 --> 00:16:41,800
Using official APIs through sanctioned connectors doesn't.

416
00:16:41,800 --> 00:16:45,400
The distinction is sharp, it's not gray, it matters legally and commercially.

417
00:16:45,400 --> 00:16:47,200
Custom integrations are powerful,

418
00:16:47,200 --> 00:16:50,400
but they're also where your governance matters most.

419
00:16:50,400 --> 00:16:52,600
Dynamics 365 Native integration.

420
00:16:52,600 --> 00:16:54,600
We've looked at the APIs, the officials think,

421
00:16:54,600 --> 00:16:56,400
and how to build custom connectors.

422
00:16:56,400 --> 00:16:58,000
But there's something most people miss.

423
00:16:58,000 --> 00:16:59,800
Dynamics 365.

424
00:16:59,800 --> 00:17:01,800
Sales already has LinkedIn capabilities

425
00:17:01,800 --> 00:17:03,400
built right into the core.

426
00:17:03,400 --> 00:17:05,000
You don't need to build a single thing.

427
00:17:05,000 --> 00:17:06,700
You don't need power automate.

428
00:17:06,700 --> 00:17:08,500
You don't need a line of custom code.

429
00:17:08,500 --> 00:17:09,600
The features are already there.

430
00:17:09,600 --> 00:17:11,400
They're just waiting for you to turn them on.

431
00:17:11,400 --> 00:17:13,700
This is where your organization should actually start.

432
00:17:13,700 --> 00:17:15,500
Not with complex integrations.

433
00:17:15,500 --> 00:17:16,900
Not with custom orchestration.

434
00:17:16,900 --> 00:17:18,400
You should start with the native features

435
00:17:18,400 --> 00:17:20,400
that Microsoft and LinkedIn build together.

436
00:17:20,400 --> 00:17:23,000
The first piece is the LinkedIn Sales Navigator card.

437
00:17:23,000 --> 00:17:26,800
This lives directly inside your contact and lead forms in Dynamics 365.

438
00:17:26,800 --> 00:17:28,000
When you open a contact record,

439
00:17:28,000 --> 00:17:30,400
you see the standard fields like name and phone number.

440
00:17:30,400 --> 00:17:33,500
But right next to them is a card showing the live LinkedIn profile.

441
00:17:33,500 --> 00:17:36,100
It shows their current role, their job history,

442
00:17:36,100 --> 00:17:38,000
and how many mutual connections you share.

443
00:17:38,000 --> 00:17:39,500
You never have to leave Dynamics.

444
00:17:39,500 --> 00:17:42,600
You don't have to open a new tab or search for them manually

445
00:17:42,600 --> 00:17:44,100
because the context is already there,

446
00:17:44,100 --> 00:17:45,700
integrated into the screen you're using.

447
00:17:45,700 --> 00:17:49,200
This isn't just a static screenshot of a profile embedded in a frame.

448
00:17:49,200 --> 00:17:50,300
It's a live connection.

449
00:17:50,300 --> 00:17:52,900
When a prospect updates their job title on LinkedIn,

450
00:17:52,900 --> 00:17:55,200
that change shows up on the card immediately.

451
00:17:55,200 --> 00:17:56,600
If they post an update, you see it.

452
00:17:56,600 --> 00:17:58,000
It's real-time information.

453
00:17:58,000 --> 00:18:01,000
Not all data that was pulled once and then set their getting dusty.

454
00:18:01,000 --> 00:18:03,000
The second capability is TeamLink.

455
00:18:03,000 --> 00:18:05,600
This solves a massive problem in account-based selling.

456
00:18:05,600 --> 00:18:08,100
You're working in account and you know who the key players are.

457
00:18:08,100 --> 00:18:11,000
But do you know if anyone else in your company already knows them?

458
00:18:11,000 --> 00:18:12,200
TeamLink answers that.

459
00:18:12,200 --> 00:18:15,800
It shows you which of your colleagues are already connected to that prospect on LinkedIn.

460
00:18:15,800 --> 00:18:16,900
This helps you in two ways.

461
00:18:16,900 --> 00:18:18,500
First, it finds warm introductions,

462
00:18:18,500 --> 00:18:20,500
so you can stop sending cold messages.

463
00:18:20,500 --> 00:18:22,500
Second, it prevents those awkward moments

464
00:18:22,500 --> 00:18:26,400
where three different people from your team reach out to the same person at the same time.

465
00:18:26,400 --> 00:18:29,100
TeamLink stops that duplication before it happens.

466
00:18:29,100 --> 00:18:31,300
The third feature is lead-in-contact creation.

467
00:18:31,300 --> 00:18:34,500
You find someone in sales navigator who looks like a perfect fit

468
00:18:34,500 --> 00:18:37,200
and you create them as a lead in Dynamics with one click.

469
00:18:37,200 --> 00:18:41,700
The system pulls the name, title, company, and LinkedIn URL to build the record for you.

470
00:18:41,700 --> 00:18:43,200
It even runs duplicate detection,

471
00:18:43,200 --> 00:18:45,500
so you don't end up with five versions of the same person.

472
00:18:45,500 --> 00:18:47,500
It saves time and it keeps your data clean.

473
00:18:47,500 --> 00:18:49,300
The fourth piece is ActivitySync.

474
00:18:49,300 --> 00:18:51,500
When a prospect sends you a message or an in-mail,

475
00:18:51,500 --> 00:18:54,500
those interactions show up in the Dynamics Timeline automatically.

476
00:18:54,500 --> 00:18:56,000
You don't have to log them yourself.

477
00:18:56,000 --> 00:18:57,900
The relationship history stays complete.

478
00:18:57,900 --> 00:19:00,400
A seller can look at a record and see the whole story.

479
00:19:00,400 --> 00:19:04,700
Not just the emails, but the LinkedIn messages and connection requests all in one sequence.

480
00:19:04,700 --> 00:19:07,700
To use this, you need sales navigator enterprise licensing.

481
00:19:07,700 --> 00:19:10,200
You'll have to enable the features and map your fields.

482
00:19:10,200 --> 00:19:11,700
But once that's done, they just work.

483
00:19:11,700 --> 00:19:13,800
No API calls, no custom flows,

484
00:19:13,800 --> 00:19:17,100
it's native product capability designed for exactly this moment.

485
00:19:17,100 --> 00:19:19,400
For most teams, this is the right place to begin.

486
00:19:19,400 --> 00:19:21,100
Master the native features first.

487
00:19:21,100 --> 00:19:23,400
See what they can do and find where the gaps are.

488
00:19:23,400 --> 00:19:26,300
Only after you've pushed the out-of-the-box tools to their limit,

489
00:19:26,300 --> 00:19:28,300
should you start building something custom.

490
00:19:28,300 --> 00:19:30,600
Native features solve the data movement problem,

491
00:19:30,600 --> 00:19:32,300
but they don't answer the deeper question.

492
00:19:32,300 --> 00:19:34,100
What does all this data actually mean?

493
00:19:34,100 --> 00:19:35,100
Relationship health?

494
00:19:35,100 --> 00:19:36,600
The signal? Not the metric.

495
00:19:36,600 --> 00:19:37,900
So the data is flowing.

496
00:19:37,900 --> 00:19:41,100
Leads are syncing and records are enriching themselves with LinkedIn info.

497
00:19:41,100 --> 00:19:43,100
The system is finally aware of what's happening,

498
00:19:43,100 --> 00:19:45,300
but awareness isn't the same as understanding.

499
00:19:45,300 --> 00:19:49,500
Understanding comes next and it happens through a feature called Relationship Health Scoring.

500
00:19:49,500 --> 00:19:52,300
The system looks at every bit of activity tied to an account.

501
00:19:52,300 --> 00:19:55,900
It looks at the emails, the phone calls, the meetings, and the LinkedIn messages.

502
00:19:55,900 --> 00:19:57,100
It analyzes the patterns.

503
00:19:57,100 --> 00:19:58,200
How often are you talking?

504
00:19:58,200 --> 00:19:59,500
When was the last time they replied?

505
00:19:59,500 --> 00:20:01,100
What's the tone of the conversation?

506
00:20:01,100 --> 00:20:04,500
It takes all of those signals and turns them into a single score.

507
00:20:04,500 --> 00:20:06,300
This score isn't based on a feeling.

508
00:20:06,300 --> 00:20:07,900
It's a weighted calculation.

509
00:20:07,900 --> 00:20:11,500
And those weights matter because they reflect how your team actually sells.

510
00:20:11,500 --> 00:20:14,000
In this model, an email might be worth three points,

511
00:20:14,000 --> 00:20:15,400
while a phone call is worth four.

512
00:20:15,400 --> 00:20:17,600
You might decide a meeting is worth seven points

513
00:20:17,600 --> 00:20:20,300
because meetings move deals faster than anything else.

514
00:20:20,300 --> 00:20:24,300
You could even set a LinkedIn profile view to one point for early stage interest.

515
00:20:24,300 --> 00:20:26,300
The system doesn't force these numbers on you.

516
00:20:26,300 --> 00:20:29,300
You define them based on what actually moves the needle for your business.

517
00:20:29,300 --> 00:20:33,300
Beyond the points, the system learns what normal looks like for your company.

518
00:20:33,300 --> 00:20:35,800
Normal might be talking to a hot prospect once a week

519
00:20:35,800 --> 00:20:37,800
or checking in with a long-term account once a month.

520
00:20:37,800 --> 00:20:39,300
The system builds a baseline.

521
00:20:39,300 --> 00:20:43,300
When the frequency of communication drops below that line, it creates a signal.

522
00:20:43,300 --> 00:20:46,800
If a prospect you talk to every week suddenly goes silent for 20 days,

523
00:20:46,800 --> 00:20:47,800
that's a signal.

524
00:20:47,800 --> 00:20:50,800
The health score will drop to reflect that change.

525
00:20:50,800 --> 00:20:52,300
Recenty is a huge part of the math.

526
00:20:52,300 --> 00:20:55,800
A call from last Tuesday carries way more weight than a call from last year.

527
00:20:55,800 --> 00:20:59,300
This stops old activity from making a dead relationship look healthy.

528
00:20:59,300 --> 00:21:03,800
You don't want one great meeting from three months ago to hide the fact that the prospect has stopped responding.

529
00:21:03,800 --> 00:21:06,300
The calculation prioritizes what is happening right now.

530
00:21:06,300 --> 00:21:07,800
Then there's sentiment analysis.

531
00:21:07,800 --> 00:21:11,300
The system looks at the actual words in your emails and call transcripts.

532
00:21:11,300 --> 00:21:12,300
It checks the tone.

533
00:21:12,300 --> 00:21:13,300
Are they excited?

534
00:21:13,300 --> 00:21:14,800
Are they hesitant or frustrated?

535
00:21:14,800 --> 00:21:16,300
The sentiment feeds the score.

536
00:21:16,300 --> 00:21:20,800
Three enthusiastic emails about a proposal are worth more than three short dismissive replies.

537
00:21:20,800 --> 00:21:22,800
The score shows you that difference.

538
00:21:22,800 --> 00:21:23,800
All of this results in a grade.

539
00:21:23,800 --> 00:21:25,800
Poor, fair, good or excellent.

540
00:21:25,800 --> 00:21:26,800
These aren't guesses.

541
00:21:26,800 --> 00:21:28,300
They are data-driven assessments.

542
00:21:28,300 --> 00:21:31,800
An excellent relationship has frequent positive recent engagement.

543
00:21:31,800 --> 00:21:35,800
A poor relationship is defined by silence or negative feedback.

544
00:21:35,800 --> 00:21:37,800
But here's the most important part.

545
00:21:37,800 --> 00:21:39,800
This isn't about replacing your judgment.

546
00:21:39,800 --> 00:21:40,800
It's the opposite.

547
00:21:40,800 --> 00:21:44,300
Humans are actually pretty bad at tracking patterns across hundreds of different relationships.

548
00:21:44,300 --> 00:21:48,300
A sales manager can't keep 50 accounts in their head and remember which ones are cooling off.

549
00:21:48,300 --> 00:21:49,300
But the system can.

550
00:21:49,300 --> 00:21:52,300
It tracks everything at once and points you toward the ones that need help.

551
00:21:52,300 --> 00:21:54,800
The health score is a signal for you to interpret.

552
00:21:54,800 --> 00:21:58,800
If a strategic account shows a declining score, that should start a conversation.

553
00:21:58,800 --> 00:22:00,300
Why is it cooling off?

554
00:22:00,300 --> 00:22:01,800
Is there a competitor in the mix?

555
00:22:01,800 --> 00:22:02,800
Is your contact just busy?

556
00:22:02,800 --> 00:22:05,300
A manager with that signal can ask much better questions.

557
00:22:05,300 --> 00:22:09,800
A leader looking at scores across the whole company can spot trends before they become problems.

558
00:22:09,800 --> 00:22:10,800
This is different from automation.

559
00:22:10,800 --> 00:22:14,300
You aren't telling the system to reassign a deal just because a score dropped.

560
00:22:14,300 --> 00:22:16,300
That would be trying to replace the human.

561
00:22:16,300 --> 00:22:18,300
Instead, you're making the invisible visible.

562
00:22:18,300 --> 00:22:19,800
The score is just information.

563
00:22:19,800 --> 00:22:21,800
What you do with it is still a human decision.

564
00:22:21,800 --> 00:22:23,300
The architecture here is live.

565
00:22:23,300 --> 00:22:27,300
The score updates the moment a seller logs a call or a prospect replies to an email.

566
00:22:27,300 --> 00:22:29,800
When something happens on LinkedIn, the score changes.

567
00:22:29,800 --> 00:22:31,300
It's not a report you run once a week.

568
00:22:31,300 --> 00:22:32,800
It's a real-time view of your business.

569
00:22:32,800 --> 00:22:34,300
You see the pattern as it forms.

570
00:22:34,300 --> 00:22:36,300
Not weeks after it's too late to do anything.

571
00:22:36,300 --> 00:22:37,800
Your judgment is still the driver.

572
00:22:37,800 --> 00:22:38,800
But now,

573
00:22:38,800 --> 00:22:41,300
it's informed by data that used to be invisible.

574
00:22:41,300 --> 00:22:44,300
Copilot for sales from inside to action.

575
00:22:44,300 --> 00:22:46,300
Visibility is only the first part of the problem.

576
00:22:46,300 --> 00:22:48,300
You can see the health of a relationship.

577
00:22:48,300 --> 00:22:49,800
You can see the activity flowing in.

578
00:22:49,800 --> 00:22:51,800
You can see patterns across your entire portfolio.

579
00:22:51,800 --> 00:22:52,800
But seeing is not doing.

580
00:22:52,800 --> 00:22:54,800
Visibility without action is just noise.

581
00:22:54,800 --> 00:22:57,300
That's where copilot for sales enters the architecture.

582
00:22:57,300 --> 00:22:58,800
Copilot is an orchestrator.

583
00:22:58,800 --> 00:23:03,800
Its job is to take relationship data, linked in signals, CRM history and outlook interactions,

584
00:23:03,800 --> 00:23:06,800
and synthesize them into something a seller can actually use.

585
00:23:06,800 --> 00:23:07,800
It isn't a report.

586
00:23:07,800 --> 00:23:08,800
It isn't a dashboard.

587
00:23:08,800 --> 00:23:10,300
It isn't another thing you have to check.

588
00:23:10,300 --> 00:23:14,300
It's an immediate conversational insight that appears where you're already working.

589
00:23:14,300 --> 00:23:15,800
Let's look at how this works in practice.

590
00:23:15,800 --> 00:23:17,800
You're preparing for a call with a prospect.

591
00:23:17,800 --> 00:23:21,800
Usually you'd spend 30 minutes researching them by pulling up LinkedIn in one tab

592
00:23:21,800 --> 00:23:24,300
and email history in another while checking internal notes.

593
00:23:24,300 --> 00:23:25,800
Now you just ask copilot.

594
00:23:25,800 --> 00:23:28,300
Prepare me for my call with Sarah-Channett AgmeCorp.

595
00:23:28,300 --> 00:23:29,800
Copilot does the work.

596
00:23:29,800 --> 00:23:32,800
It pulls her LinkedIn profile to show her current role in recent activity.

597
00:23:32,800 --> 00:23:36,300
It scans your recent emails to understand the context of the conversation.

598
00:23:36,300 --> 00:23:39,300
It looks at the opportunity record to see where the deal stands.

599
00:23:39,300 --> 00:23:41,300
Within seconds it returns a briefing.

600
00:23:41,300 --> 00:23:42,300
It isn't a data dump.

601
00:23:42,300 --> 00:23:43,300
It's a narrative.

602
00:23:43,300 --> 00:23:47,300
It tells you who Sarah is, what you've been discussing, and what she might be thinking about

603
00:23:47,300 --> 00:23:49,300
based on recent changes in her role.

604
00:23:49,300 --> 00:23:51,300
It even lists your internal advocates.

605
00:23:51,300 --> 00:23:53,800
This is synthesis.copilot isn't creating new data.

606
00:23:53,800 --> 00:23:57,300
It's reading information that already exists in your system and presenting it in a way

607
00:23:57,300 --> 00:23:58,800
that's actually useful in the moment.

608
00:23:58,800 --> 00:24:00,300
Email drafting works the same way.

609
00:24:00,300 --> 00:24:03,300
You want to respond to a prospect, but you want it to be personalized.

610
00:24:03,300 --> 00:24:07,300
You tell copilot you need to follow up with Marcus about the budget conversation from last week

611
00:24:07,300 --> 00:24:10,300
and ask it to keep the tone friendly but focused on next steps.

612
00:24:10,300 --> 00:24:11,800
Copilot reads the thread.

613
00:24:11,800 --> 00:24:13,300
It understands the relationship dynamic.

614
00:24:13,300 --> 00:24:14,300
It knows what was discussed.

615
00:24:14,300 --> 00:24:18,300
Then it drafts something that sounds like you but is informed by the full context.

616
00:24:18,300 --> 00:24:22,300
The email lands differently when it references something specific from your last talk.

617
00:24:22,300 --> 00:24:24,300
It shows you a paying attention.

618
00:24:24,300 --> 00:24:28,300
It flows from what you actually know about the person instead of being a template with a name inserted.

619
00:24:28,300 --> 00:24:31,300
Opportunity summaries follow this same model.

620
00:24:31,300 --> 00:24:35,300
Copilot pulls together the account context, the stage of the deal and the risk factors.

621
00:24:35,300 --> 00:24:37,300
It tells you what's happening in natural language.

622
00:24:37,300 --> 00:24:42,300
It doesn't say stage 3, $250,000 last activity three days ago.

623
00:24:42,300 --> 00:24:47,300
It says this deal is moving, but your relationship with the technical buyer is cold.

624
00:24:47,300 --> 00:24:48,300
The financial buyer is engaged.

625
00:24:48,300 --> 00:24:50,300
The champion is responsive but stretched.

626
00:24:50,300 --> 00:24:55,300
If the technical buyer doesn't re-engage in the next two weeks, this flips to a loss scenario.

627
00:24:55,300 --> 00:24:58,300
The next best action is where copilot becomes prescriptive.

628
00:24:58,300 --> 00:25:02,300
Based on relationship health and the competitive landscape, it suggests what should happen next.

629
00:25:02,300 --> 00:25:05,300
It isn't a list of options. It's a recommendation.

630
00:25:05,300 --> 00:25:09,300
It might tell you to follow up with Lisa directly because the committee isn't moving things forward.

631
00:25:09,300 --> 00:25:11,300
And she has the authority to decide.

632
00:25:11,300 --> 00:25:17,300
It suggests using a specific angle about the implementation timeline because that's what is actually holding them back.

633
00:25:17,300 --> 00:25:19,300
The architecture behind this is what matters.

634
00:25:19,300 --> 00:25:22,300
Copilot isn't holding data or creating a separate system of truth.

635
00:25:22,300 --> 00:25:26,300
It reads from the sources you already have like Dynamics 365, LinkedIn and Teams.

636
00:25:26,300 --> 00:25:29,300
It only sees what the user is permitted to see.

637
00:25:29,300 --> 00:25:31,300
It respects your security roles.

638
00:25:31,300 --> 00:25:36,300
If a seller doesn't have access to an opportunity record, copilot won't share insights from that record with them.

639
00:25:36,300 --> 00:25:41,300
The access boundaries stay in place. This means copilot isn't replacing seller judgment. It's amplifying it.

640
00:25:41,300 --> 00:25:44,300
The seller still decides how to approach the prospect and when to push.

641
00:25:44,300 --> 00:25:47,300
But they're making that decision with better information.

642
00:25:47,300 --> 00:25:49,300
They see the full picture instead of fragments.

643
00:25:49,300 --> 00:25:53,300
They work from what's actually true instead of what they can remember or have time to look up.

644
00:25:53,300 --> 00:25:54,300
The effect compounds.

645
00:25:54,300 --> 00:25:57,300
Sellers spend less time on research and more time on relationships.

646
00:25:57,300 --> 00:26:01,300
They spend less time in browsers and more time in conversations building trust.

647
00:26:01,300 --> 00:26:04,300
The work shifts from information gathering to decision making.

648
00:26:04,300 --> 00:26:10,300
Human capability improves when the tool does the work humans are slow at and hands back the judgment humans are good at.

649
00:26:10,300 --> 00:26:13,300
Sales agents. Autonomous research and qualification.

650
00:26:13,300 --> 00:26:17,300
Up until now we've been talking about systems that amplify what a human can do.

651
00:26:17,300 --> 00:26:19,300
Copilot waits for a question.

652
00:26:19,300 --> 00:26:25,300
A seller asks and copilot synthesizes. A human interprets the data. The human remains at the center of the loop.

653
00:26:25,300 --> 00:26:28,300
The next layer shifts that dynamic, not because humans become less important.

654
00:26:28,300 --> 00:26:31,300
But because entire classes of work become automated.

655
00:26:31,300 --> 00:26:34,300
The sales agent is a copilot studio agent that runs autonomously.

656
00:26:34,300 --> 00:26:36,300
It doesn't wait for a seller to ask a question.

657
00:26:36,300 --> 00:26:39,300
It doesn't need a human prompt. It operates on a schedule or on triggers.

658
00:26:39,300 --> 00:26:42,300
When conditions change, it acts. Here's the operating model.

659
00:26:42,300 --> 00:26:48,300
A new lead arrives in Dynamics 365. This might be someone who filled out a form on your website or someone imported from a campaign.

660
00:26:48,300 --> 00:26:53,300
The moment that lead record is created, the sales agent wakes up. It doesn't wait for a seller to notice.

661
00:26:53,300 --> 00:26:57,300
It doesn't depend on someone finding time to research. It starts working immediately.

662
00:26:57,300 --> 00:27:02,300
The agent researches the company. It pulls information about their market position, recent news and funding activity.

663
00:27:02,300 --> 00:27:07,300
It maps the buying committee. It identifies the likely decision makers and blockers based on the industry.

664
00:27:07,300 --> 00:27:10,300
It scores the opportunity based on fit.

665
00:27:10,300 --> 00:27:16,300
It asks, does this company match your ideal customer profile? How urgent is their problem? How well positioned is your solution?

666
00:27:16,300 --> 00:27:20,300
The agent uses LinkedIn as a primary signal layer for this analysis.

667
00:27:20,300 --> 00:27:23,300
Job changes matter because they indicate changes in priorities.

668
00:27:23,300 --> 00:27:27,300
When a company hires a new VP of operations, that's a buying signal.

669
00:27:27,300 --> 00:27:31,300
Someone in that role is likely evaluating tools to help them operate more efficiently.

670
00:27:31,300 --> 00:27:33,300
New connections show organizational movement.

671
00:27:33,300 --> 00:27:36,300
Engagement patents show who is active in the market.

672
00:27:36,300 --> 00:27:41,300
If an account that's been dormant on LinkedIn suddenly has activity, it could indicate a hiring cycle or a strategic shift.

673
00:27:41,300 --> 00:27:43,300
There are two specific agents to watch.

674
00:27:43,300 --> 00:27:47,300
The sales development agent goes live in July of 2026.

675
00:27:47,300 --> 00:27:53,300
This agent specializes in the SDR workflow by finding leads and qualifying them for handoff to AES.

676
00:27:53,300 --> 00:27:56,300
The sales research agent goes live in April of 2026.

677
00:27:56,300 --> 00:28:01,300
This one digs into market data and competitor activity for deep account intelligence.

678
00:28:01,300 --> 00:28:03,300
The output they produce is structured.

679
00:28:03,300 --> 00:28:07,300
It isn't a wall of text. It's organized information designed for human decision making.

680
00:28:07,300 --> 00:28:10,300
You get a research summary explaining what the agent found. You get a confidence score.

681
00:28:10,300 --> 00:28:18,300
You get a recommended next action. It might tell you to escalate because the fit is exceptional or to deprioritize because the opportunity isn't real.

682
00:28:18,300 --> 00:28:22,300
It provides a list of stakeholders with reasoning for why those specific people matter.

683
00:28:22,300 --> 00:28:26,300
This is the shift. Sellers don't have to do the research. They get a brief and a strategy.

684
00:28:26,300 --> 00:28:33,300
The work that used to take an SDR two hours, researching an account and figuring out who to approach, an agent completes in seconds.

685
00:28:33,300 --> 00:28:37,300
The output isn't always perfect. Sometimes the agent misses context a human would catch.

686
00:28:37,300 --> 00:28:41,300
But it's good enough to be useful. And it's fast enough that a seller can act on it immediately.

687
00:28:41,300 --> 00:28:46,300
The time math is real. A human SDR might spend 30 minutes researching a prospect before they're ready to reach out.

688
00:28:46,300 --> 00:28:52,300
An agent does it in seconds. When you multiply that across 100 daily leads, the impact is massive.

689
00:28:52,300 --> 00:28:56,300
But the real impact isn't just time-saved. It's the shift in what humans do with that time.

690
00:28:56,300 --> 00:29:00,300
Instead of research, they prospect. Instead of data gathering, they build relationships.

691
00:29:00,300 --> 00:29:04,300
The agents don't replace sellers. They handle the work that was always in the way.

692
00:29:04,300 --> 00:29:08,300
The orchestrator pattern. A single agent can handle a narrow task well.

693
00:29:08,300 --> 00:29:14,300
But real sales processes aren't narrow. They're complex. They require research, qualification and strategy development.

694
00:29:14,300 --> 00:29:18,300
You need customer data and market context and competitive analysis all at once.

695
00:29:18,300 --> 00:29:24,300
When one agent tries to do all of that, it becomes unfocused. It gets bogged down because it tries to hold too much in its reasoning at once.

696
00:29:24,300 --> 00:29:29,300
And the output suffers. The solution is to stop thinking about a single agent doing all the work.

697
00:29:29,300 --> 00:29:36,300
Instead, think about multiple specialist agents. Each could at one thing. Coordinated by an orchestrator that decides which agent should do what.

698
00:29:36,300 --> 00:29:41,300
Here's how the orchestrator pattern works in practice. The new account arrives in Dynamics 365.

699
00:29:41,300 --> 00:29:46,300
This could be a company that signed up for a trial. Or a target account your sales leadership wants to pursue.

700
00:29:46,300 --> 00:29:52,300
The moment that record is created, the orchestrator agent wakes up. It doesn't do the research itself. It delegates.

701
00:29:52,300 --> 00:29:56,300
It roots the account to a research agent that specializes in gathering intelligence about companies.

702
00:29:56,300 --> 00:30:06,300
Looking at market position, funding, news and organizational structure. At the same time, it roots that same account to a qualification agent to see if they match your ideal customer profile.

703
00:30:06,300 --> 00:30:11,300
In parallel, it sends the data to a strategy agent that looks at competitive positioning and recommends the best approach.

704
00:30:11,300 --> 00:30:18,300
Three agents working at the same time on the same account. Each one doing exactly what it was built to do. The orchestrator watches.

705
00:30:18,300 --> 00:30:22,300
When all three have completed their work, it collects the outputs.

706
00:30:22,300 --> 00:30:28,300
The research agent returns a company overview and an org chart. The qualification agent returns a fit score with an explanation.

707
00:30:28,300 --> 00:30:36,300
And the strategy agent returns recommended positioning and talking points. The orchestrator synthesizes all three into a single coherent brief for the sales team.

708
00:30:36,300 --> 00:30:41,300
Not three separate reports that someone has to read through and piece together. A unified narrative.

709
00:30:41,300 --> 00:30:45,300
Here's what we know about this company. Here's why they're a fit. Here's how we should approach them.

710
00:30:45,300 --> 00:30:51,300
The orchestrator doesn't do the work. It decides who should do it in what order and how to combine the results.

711
00:30:51,300 --> 00:30:57,300
This is the critical distinction. The orchestrator is a coordinator not a performer. This pattern scales dramatically.

712
00:30:57,300 --> 00:31:01,300
You could have ten specialist agents. 20. 50.

713
00:31:01,300 --> 00:31:06,300
Each one focused on a specific domain like lead research, account enrichment, or opportunity scoring.

714
00:31:06,300 --> 00:31:11,300
The orchestrator roots work to the right specialist without overloading any single agent or creating a bottleneck.

715
00:31:11,300 --> 00:31:19,300
The orchestrator uses decision logic that makes the rooting intelligent. If an account has an annual contract value over $1 million, it goes to the enterprise agent.

716
00:31:19,300 --> 00:31:26,300
If it's marked as a renewal opportunity, it goes to the renewal agent. If it's early stage with unqualified fit signals, it goes to the disqualification agent.

717
00:31:26,300 --> 00:31:31,300
The orchestrator reads the incoming data and makes rooting decisions based on the characteristics of what it's processing.

718
00:31:31,300 --> 00:31:38,300
This creates a system that's both specialized and adaptive. Each agent gets better at its specific task. Because that's all it does.

719
00:31:38,300 --> 00:31:44,300
The orchestrator ensures that the right specialist handles the right work. A research expert doesn't spend cycles on deal qualification.

720
00:31:44,300 --> 00:31:51,300
An equalification expert doesn't waste time on strategy development. Everyone focuses. The pattern also improves reliability.

721
00:31:51,300 --> 00:31:56,300
In a single agent system, if the agent fails or gets stuck on a difficult case, everything holds.

722
00:31:56,300 --> 00:32:02,300
In an orchestrator pattern, if one specialist agent fails, the orchestrator knows about it. It can re-try that agent with a different prompt.

723
00:32:02,300 --> 00:32:09,300
It can escalate to a human, or it can root to an alternative agent if one exists. The failure of one component doesn't collapse the entire system.

724
00:32:09,300 --> 00:32:19,300
And there's a capacity benefit. A single agent might handle 50 accounts daily. 5 specialist agents each coordinated by an orchestrator can handle significantly more. The work distributes.

725
00:32:19,300 --> 00:32:27,300
The throughput increases. The latency decreases because work happens in parallel instead of waiting in a line. Context switching also drops.

726
00:32:27,300 --> 00:32:37,300
Each agent stays focused on its domain. It doesn't have to shift mental models throughout the day. It gets deeper at what it does and better at catching the subtle patterns that matter in its specialty.

727
00:32:37,300 --> 00:32:44,300
The orchestrator pattern is where the architecture moves from, having agents to having agent systems. That's where the real scaling begins.

728
00:32:44,300 --> 00:32:52,300
Sequential versus concurrent orchestration. The orchestrator pattern we just described works when agents perform work in sequence. One finishes, another begins.

729
00:32:52,300 --> 00:32:59,300
The output of the first becomes the input for the second. This creates a clear, predictable chain. But it's not the only way orchestration can work.

730
00:32:59,300 --> 00:33:09,300
And for certain types of problems, it's actually the wrong way. Understanding the difference between sequential and concurrent orchestration is about matching your architecture to the actual nature of the problem you're solving.

731
00:33:09,300 --> 00:33:19,300
In sequential orchestration agents execute one after another in a defined order. Think of it like an assembly line. The research agent completes its work on an account and hands its findings to the qualification agent.

732
00:33:19,300 --> 00:33:28,300
The qualification agent uses that research to assess fit. Then hands off to the strategy agent, which uses both the research and the qualification assessment to recommend an approach.

733
00:33:28,300 --> 00:33:43,300
Each step depends on the output of the previous step. Each agent needs that prior context to do its job well. The advantage of sequential is straightforward. Your logic is simple. You know exactly what happens in what order. The handoff points are clear. If something goes wrong at step two, you know exactly what state the system was in at that moment.

734
00:33:43,300 --> 00:33:57,300
Debugging is easier. Reliability is easier to reason about. But there's a cost time. If each agent takes five seconds to complete its work, three agents working sequentially takes 15 seconds total. That adds up when you're processing hundreds of accounts daily.

735
00:33:57,300 --> 00:34:09,300
Concurrent orchestration flips this. Multiple agents work at the same time on the same problem. The research agent, sentiment analysis agent and competitor mapping agent all process the same account simultaneously.

736
00:34:09,300 --> 00:34:17,300
Each one operates independently without waiting for the others. Once all three finish, the orchestrator merges their outputs. The benefit is speed.

737
00:34:17,300 --> 00:34:29,300
Three agents running in parallel take roughly the time of one agent. Same five second baseline, but all three complete within that window instead of sequentially. The latency drops dramatically. The tradeoff is complexity.

738
00:34:29,300 --> 00:34:39,300
Merging outputs from independent agents isn't always straightforward. If one agent concludes that the account is a perfect fit and another concludes its a poor fit, which one is right? How do you reconcile conflicting signals?

739
00:34:39,300 --> 00:35:00,300
The orchestrator needs logic to detect these conflicts and either resolve them or surface them for human judgment. The choice between sequential and concurrent depends on your workflows actual structure. For lead qualification, sequential often makes sense. You need to know what you're researching before you assess fit and you need to assess fit before you recommend a strategy. The steps build on each other. The dependencies are real.

740
00:35:00,300 --> 00:35:15,300
For account intelligence gathering concurrent makes more sense. Research, sentiment analysis and competitor tracking don't depend on each other. They're parallel work streams. You benefit from having all three completed quickly rather than waiting for them sequentially. The dependencies are weaker.

741
00:35:15,300 --> 00:35:29,300
In practice, most complex workflows end up being hybrid. Some steps run sequentially because they depend on each other. Other steps run in parallel because they're independent. The orchestrator coordinates the mix. It understands which agents need to wait for prior steps and which can work in parallel.

742
00:35:29,300 --> 00:35:45,300
The orchestrator decides the execution pattern based on the task it's processing. This is why the orchestrator is intelligent, not just a router, it reads the incoming work, understands its characteristics and determines the execution strategy that makes sense for that specific piece of work. This adaptability is where the pattern becomes powerful.

743
00:35:45,300 --> 00:35:58,300
You're not locked into one execution model. You optimize based on what you're actually trying to accomplish in each moment. The system becomes both fast and reliable because it's designed for the real structure of the work. Not for an oversimplified model of how workflows.

744
00:35:58,300 --> 00:36:11,300
API rate limits and throttling. Your architecture is built on syncs, agents and orchestrators. But all of it operates within a cage and understanding the bars of that cage isn't optional. It's foundational because the moment you ignore these constraints, your system breaks.

745
00:36:11,300 --> 00:36:24,300
Linked in enforces rate limits on its APIs. That's not a surprise. What might surprise you is how tight they actually are. Take the sales navigator API, it caps out at roughly 1000 leads and contacts per user, per month 1000, per month not per day.

746
00:36:24,300 --> 00:36:31,300
This isn't a soft suggestion or a goal to aim for. It's a hard ceiling when you hit it, you hit it. The system simply stops accepting your requests.

747
00:36:31,300 --> 00:36:42,300
Over on the Dynamics 365 side, the constraints look different but they're just as real. Dynamics has service protection limits. They exist to stop one single user's integration from slowing down the entire environment for everyone else.

748
00:36:42,300 --> 00:36:53,300
Those limits are set at 6000 requests within any 5 minute sliding window. Think about that. In a 5 minute span, if you cross that 6000 callmark, you're done. You get an HTTP 429 error.

749
00:36:53,300 --> 00:37:02,300
Too many requests. Power Automate sits in the middle and it has its own tax. Each user gets about 40,000 API requests every 24 hours depending on their license.

750
00:37:02,300 --> 00:37:11,300
That sounds like a massive number until you realize a single misconfigured flow can burn through that in minutes. One loop calling an API incorrectly. And your daily budget is gone.

751
00:37:11,300 --> 00:37:16,300
These limits aren't arbitrary penalties. They aren't there to make your life difficult. They're protective mechanisms.

752
00:37:16,300 --> 00:37:29,300
They keep the service stable in a world where millions of organizations are running millions of integrations at the same time. They enforce fairness across the platform. When you exceed a limit, the system sends back that 429 status code and a retry after header.

753
00:37:29,300 --> 00:37:35,300
That header tells you exactly how long to wait before trying again. It's not a suggestion. It's a contract if the header says wait 60 seconds.

754
00:37:35,300 --> 00:37:45,300
You wait 60 seconds. If you ignore the signal and keep hammering the API, the throttling gets aggressive. The back of time multiplies. Your requests get slower and slower until the system essentially stops talking to you.

755
00:37:45,300 --> 00:37:54,300
The practical reality is this. You cannot design integrations that assume unlimited throughput. You have to build for these constraints from day one. Batching is the first way to lower the pressure.

756
00:37:54,300 --> 00:38:11,300
Instead of updating one contact at a time in a loop, you batch 100 contacts into a single request. That counts as one API call instead of 100. The math changes instantly. You go from burning your entire power automate allocation on a few thousand records to processing hundreds of thousands without breaking a sweat. A synchronous patterns help too.

757
00:38:11,300 --> 00:38:24,300
Instead of making calls in a tight loop where you wait for each one to finish. You queue the work, you process it in the background. The concurrent load drops. The API gets breathing room. And you get better throughput because you aren't holding connections open while you wait.

758
00:38:24,300 --> 00:38:35,300
The governance side of this is where things get serious. Some organizations hit a limit and think they can just create five different app registrations to split the work. Use app one for half the load and app two for the rest.

759
00:38:35,300 --> 00:38:45,300
Double the quota. That logic is tempting until Microsoft detects the pattern and blocks you using multiple apps specifically to bypass rate limits is prohibited. And the detection is getting better every day.

760
00:38:45,300 --> 00:38:55,300
It's not something you can hide. This architecture forces you to value efficiency. You can't brute force your way through integration problems. You have to be thoughtful about how you batch data and how you structure the work.

761
00:38:55,300 --> 00:39:15,300
This isn't a sign of bad design. It's the boundary that separates systems that scale from systems that eventually collapse. The hundred second synchronous timeout power automate has a structural constraint that hits harder than rate limits. Any flow that calls an external system synchronously, meaning it sits there and waits for a response, has exactly a hundred seconds to finish, not 105, 100 seconds.

762
00:39:15,300 --> 00:39:44,300
After that threshold, power automate kills the execution, the flow fails and whatever called that flow gets nothing back. This is a massive deal when agents are involved. An agent uses a power automate flow as a tool. It makes a request, waits for the data and uses that data to think, but the agent has a time budget too. If your flow takes 110 seconds, the agent times out, the intelligence it was building collapses, the entire exchange fails. This constraint forces discipline. You have to keep the synchronous part fast. You call LinkedIn. You get the data, you return it immediately.

763
00:39:44,300 --> 00:40:12,300
No complex transformations, no long sequential loops, no waiting on three other systems. You just accept the request, fetch the data and respond. When you need to do something slow and most real work is slow, you have to split the logic. The synchronous part accepts the request and queues it. It returns a tracking ID right away. Then an asynchronous part runs separately in the background to do the heavy lifting. It handles the complex math. It calls the multiple APIs. It takes all the time it needs. When it's done, it stores the result and notifies the system.

764
00:40:12,300 --> 00:40:31,300
Let's look at a real example. An agent needs to enrich a contact with LinkedIn data. It's not just a name and title. It's a full analysis of their recent activity, engagement patterns and buying signals. That analysis is heavy. It takes multiple API calls and a lot of data processing. You cannot do that in 100 seconds while an agent is holding its breath. So the synchronous flow does this.

765
00:40:31,300 --> 00:40:42,300
It accepts the request for the contact. It validates the data. It drops the work into a processing queue. And it returns a tracking ID. The agent gets its answer in two seconds. It knows the work is happening. It can move onto other tasks.

766
00:40:42,300 --> 00:40:55,300
Meanwhile, the asynchronous flow wakes up. It sees the work in the queue. It calls the LinkedIn APIs, runs the calculations and saves the enriched record back to Dynamics 365. The whole process might take three minutes. But it doesn't matter.

767
00:40:55,300 --> 00:41:08,300
Because nobody is waiting for it. This adds complexity to your build. You aren't building one flow anymore. You're building two parts that have to talk to each other through a queue. You need monitoring on both sides. You need logic to handle what happens if the work finishes, but the caller is gone.

768
00:41:08,300 --> 00:41:22,300
But this complexity is the only way to be reliable at scale. The alternative is trying to do everything at once. You keep the agent waiting. You pray the API responds fast. And eventually you hit a timeout. You get failed requests. You get frustrated users. You get agents that break and don't know why.

769
00:41:22,300 --> 00:41:31,300
Timeouts are technical rules, but they point to a deeper principle. Separate the fast path from the slow path. Do what must be immediate synchronously. Queue everything else.

770
00:41:31,300 --> 00:41:36,300
That separation is what keeps your system alive when the workload gets heavy.

771
00:41:36,300 --> 00:41:51,300
Data governance and compliance risk. Constraints shape your architecture, but they come in two forms. You have technical constraints like rate limits and timeouts that force you to design for efficiency. Then you have regulatory constraints like data protection laws that force you to design for ethics, both matter equally.

772
00:41:51,300 --> 00:42:03,300
The governance challenge starts with a simple question. Where did this data actually come from? If you are syncing linked in contacts into Dynamics 365 through the official sales navigator CRM sync, the answer is easy.

773
00:42:03,300 --> 00:42:12,300
It is an official integration. It is sanctioned by both linked in and Microsoft. The data flow is documented and the terms are clear, but things change when you step outside those lines.

774
00:42:12,300 --> 00:42:25,300
If someone builds a custom HTTP connector to call undocumented linked in endpoints or if a power automate flow is running a third party scraping tool, you have a problem. Using browser automation to extract profiles at scale violates linked in terms of service.

775
00:42:25,300 --> 00:42:34,300
And more importantly, it often violates data protection laws. GDPR does not care how clever your integration is. It requires a lawful basis for collecting personal data.

776
00:42:34,300 --> 00:42:46,300
And linked in profiles are definitely personal data. You cannot just claim the data was publicly available on the platform. GDPR does not recognize that as a lawful excuse. You need consent, a defensible business interest or a contractual obligation.

777
00:42:46,300 --> 00:42:58,300
Simply wanting to prospect someone is not enough. The person's expectation matters. They shared their profile within LinkedIn's ecosystem, not so it could be bulk extracted for your CRM. This gets worse when you start combining different data sources.

778
00:42:58,300 --> 00:43:14,300
If you take a LinkedIn profile and match it with employee records or data from a broker, you are now profiling people. Combining disparate data to score or rank individuals triggers much higher scrutiny under GDPR and similar laws. Your regulatory burden increases and your transparency requirements become much stricter.

779
00:43:14,300 --> 00:43:34,300
The enforcement mechanism here is actually very simple. Use official APIs and sanctioned integrations only. Sales navigators CRM sync is official. The compliance APIs. LinkedIn publishes for regulated industries are official. Custom HTTP calls to unpublished endpoints are not. Power automate flows that script browser automation are not. The line is clear even if the incentive to cross it is tempting.

780
00:43:34,300 --> 00:43:50,300
DLP policies act as your governance fence. You need to restrict which power automate connectors can handle data sourced from LinkedIn. You can configure your tenants so that generic HTTP connectors cannot receive data from lead records that started in LinkedIn. You can also restrict the export of contact lists to only approve destinations.

781
00:43:50,300 --> 00:44:00,300
Blocking unknown external services prevents data leakage. These policies stop a flow from accidentally or intentionally sending prospect data somewhere it should not go.

782
00:44:00,300 --> 00:44:14,300
The rules are how you prove you are following the rules. Native Dynamics 365 logging captures who accessed what data when they did it and why. The system records every API call every record view and every data export.

783
00:44:14,300 --> 00:44:29,300
If a compliance auditor asks to see everyone who touched a specific contact record, you have the full history. Custom scrapers operate in the dark and generate no audit trail. When something goes wrong you cannot reconstruct what happened. The compliance risk compounds because once this data enters your system you are responsible for it.

784
00:44:29,300 --> 00:44:42,300
You are now the data controller. LinkedIn is no longer the primary custodian. You own the obligation to secure it, respond to data requests and delete it when necessary. If you scraped that data through unauthorized means you are starting from a position of violation.

785
00:44:42,300 --> 00:44:50,300
The entire relationship is tainted from day one. The business consequences are massive. GDPR fines can reach 20 million euros or 4% of your global annual revenue.

786
00:44:50,300 --> 00:45:06,300
In California, CCPA violations can hit $1,500 per person. A single aggressive scraping campaign that harvests 10,000 profiles could generate fines in the tens of millions. That is not a theoretical threat. That is the enforcement reality we are seeing in 2026. The governance implication is straightforward.

787
00:45:06,300 --> 00:45:19,300
Treat LinkedIn data like regulated data. Apply the same controls you would use for financial records, restrict the access, audit the usage, document your lawful basis, respect the rights of the people behind the data. This is not just bureaucracy. It is foundation building.

788
00:45:19,300 --> 00:45:32,300
Organizations that move data through official channels can scale with confidence. Those that take shortcuts live in perpetual risk. Constraints and risks shape your architecture. They are not obstacles. They are guardrails. They define the only path you can actually walk safely.

789
00:45:32,300 --> 00:45:47,300
Building the unified system. Everything we have covered so far, the API is the SYNC, the health scoring, co-pilot and the governance all fits into a single architecture. This is not just a collection of features. It is a coherent system where every layer depends on the others and nothing works in isolation.

790
00:45:47,300 --> 00:45:55,300
Think of this unified system as three distinct layers. Each one has a specific responsibility and the system only works when all three function together.

791
00:45:55,300 --> 00:46:05,300
The extraction layer is where it starts. This is where data enters the system. Sales Navigator CRM SYNC brings in leads and engagement signals from LinkedIn on a daily schedule. Dynamics.

792
00:46:05,300 --> 00:46:11,300
365. Relationship health scoring calculates strength based on the activity already captured in your CRM.

793
00:46:11,300 --> 00:46:23,300
Email interactions, calls, meetings and LinkedIn messages all feed into this layer. This layer answers one question. What is actually happening in the relationship? The data flows in continuously. It is not a batch job that runs once a week.

794
00:46:23,300 --> 00:46:29,300
As activity happens, the signals flow. The reasoning layer sits right above extraction. This is where meaning is created.

795
00:46:29,300 --> 00:46:40,300
Co-pilot synthesizes that extracted data into actionable insights. It reads the CRM records, the LinkedIn signals and the outlook history to generate a narrative. It tells you why a relationship is healthy or why it is declining.

796
00:46:40,300 --> 00:46:45,300
It answers the question of what should happen next and where your attention should go. This is also where your agents operate.

797
00:46:45,300 --> 00:46:55,300
The sales research agent takes the raw data and finds patterns that are not immediately obvious. The sales development agent qualifies leads based on that data to make judgments about fit and priority.

798
00:46:55,300 --> 00:47:02,300
The reasoning layer does not create new data. It turns existing data into intelligence. The action layer executes decisions based on that intelligence.

799
00:47:02,300 --> 00:47:12,300
Power Automate flows root qualified leads from the reasoning layer to the right sellers. If a lead comes through tagged as enterprise segment, the flow roots it to your enterprise team.

800
00:47:12,300 --> 00:47:22,300
If a relationship health score drops below a certain threshold, the flow generates an alert for the account owner. When an agent recommends that a contact needs a follow-up, the flow creates a task for the seller.

801
00:47:22,300 --> 00:47:32,300
The action layer turns your insight into actual motion. The system is continuous because the data never stops moving. A prospect opens an email from a seller and that activity is logged immediately.

802
00:47:32,300 --> 00:47:37,300
The relationship health updates and co-pilot sees the new signal. The reasoning layer then adjusts its assessment.

803
00:47:37,300 --> 00:47:43,300
If that activity moves the relationship from fair to good health, the action layer removes any at-risk escalation that was triggered.

804
00:47:43,300 --> 00:47:49,300
The system evolves as reality evolves. You are not working from reports that were accurate last week. You are working from real-time truth.

805
00:47:49,300 --> 00:47:56,300
The benefit here is not just about efficiency, even though efficiency matters. The core benefit is the quality of your decisions.

806
00:47:56,300 --> 00:48:05,300
A seller preparing for a call does not have to guess at what matters because co-pilot shows them. They see the health trends, the recent engagement, and which internal stakeholders are involved.

807
00:48:05,300 --> 00:48:14,300
They make decisions based on current information. They are not relying on memory or assumptions or fragments of context scattered across different systems. They have integrated accurate information.

808
00:48:14,300 --> 00:48:19,300
The architecture is designed for reality, not for an ideal world where everything is perfect.

809
00:48:19,300 --> 00:48:27,300
API limits exist, so the system batches and throttles your data intelligently. Timeouts happen, so the synchronous and asynchronous work is separated cleanly.

810
00:48:27,300 --> 00:48:32,300
Governance requirements are real, so the system logs everything and respects your access boundaries.

811
00:48:32,300 --> 00:48:38,300
The architecture is not fighting these constraints. It is built around them. The system is fully auditable. Every action is logged.

812
00:48:38,300 --> 00:48:44,300
If an agent makes a decision about whether to prioritize a lead, that decision is recorded. The reasoning is traceable.

813
00:48:44,300 --> 00:48:51,300
If a seller acts on a recommendation from co-pilot, that moment is logged. If a power automate flow escalates in account, the trigger condition is documented.

814
00:48:51,300 --> 00:48:58,300
When something goes wrong, you can reconstruct exactly what happened and why. This matters for your operations because it helps you improve the system.

815
00:48:58,300 --> 00:49:05,300
It matters legally because auditors want to see the decision trail. It matters competitively because you finally understand what is working.

816
00:49:05,300 --> 00:49:13,300
This is the unified system. Extraction feeds reasoning. Reesoning feeds action. The whole thing runs in a loop. Data flows in, intelligence emerges and decisions execute.

817
00:49:13,300 --> 00:49:18,300
And because every step is transparent, you can actually explain every decision the system makes.

818
00:49:18,300 --> 00:49:25,300
Implementation roadmap. The architecture makes sense on paper. But you cannot build the whole thing at once. You just can't. Your organization isn't ready for it.

819
00:49:25,300 --> 00:49:34,300
Your team doesn't have the skills yet. You haven't proven the value to the people holding the budget. If you try to deploy everything at the same time, you will burn through your credibility and your cash.

820
00:49:34,300 --> 00:49:41,300
The roadmap breaks this down into four phases over 12 months. Each phase delivers its own value. Each phase prepares the ground for the next one.

821
00:49:41,300 --> 00:49:49,300
Phase one covers months one through three. This is about the foundation. The goal is to get linked in data flowing into Dynamics 365 without any custom code.

822
00:49:49,300 --> 00:49:59,300
You enable sales navigator CRM sync and let it run daily. You get your leads syncing and watch the integration to find the basic bugs. At the same time, you configure your relationship health scoring. Start simple.

823
00:49:59,300 --> 00:50:07,300
Set your activity weights based on what you think matters right now. Maybe an email is worth three points, a call is four, and a meeting is five.

824
00:50:07,300 --> 00:50:14,300
You can always adjust those numbers later when you have real data to look at. You also need to train your sales team on the native LinkedIn features that are already in the product.

825
00:50:14,300 --> 00:50:26,300
Show them the sales navigator card in their contact forms. Show them team link. Show them how to create a lead directly from LinkedIn. This phase takes 90 days because change management is slow. People need time to get used to new tools.

826
00:50:26,300 --> 00:50:35,300
Early wins are what matter here. When sellers start seeing enriched contact records without doing any manual work, they stop resisting. They see the value. That is the goal of phase one.

827
00:50:35,300 --> 00:50:47,300
Value visibility phase two runs from month four to month six. Now you layer in the intelligence you deploy co pilot for sales. This is where the system starts synthesizing information start with the features that feel natural to your sellers.

828
00:50:47,300 --> 00:51:00,300
Meeting prep is easy to understand email drafting makes immediate sense opportunity summaries give managers the visibility they need. You should also implement data loss prevention policies at this stage restrict which connectors can handle your linked in data.

829
00:51:00,300 --> 00:51:10,300
You have to govern the flow of relationship intelligence this phase is about bringing AI into the workflow without breaking the workflow. Sellers should feel like co pilot is helping them not trying to replace them.

830
00:51:10,300 --> 00:51:18,300
The relationship health scoring you started in phase one is now feeding into co pilot insights sales managers can use co pilot to see which accounts are at risk.

831
00:51:18,300 --> 00:51:24,300
They can see which relationships are cooling and which opportunities are actually moving. This is about intelligence surfacing not autonomous agents yet.

832
00:51:24,300 --> 00:51:39,300
Phase three happens in months seven through nine. This is where autonomy enters the picture you deploy the sales agent for lead research and qualification. These agents start taking over work that used to require human time. Let them research the accounts. Let them qualify the leads. Let them map out the buying committees.

833
00:51:39,300 --> 00:51:46,300
You build power automate flows that route those qualified leads to the right sellers based on territory and skill set up your escalation rules.

834
00:51:46,300 --> 00:52:00,300
If a relationship health score drops below your threshold for a strategic account the system sends an alert to the owner. No more manual monitoring no more checking dashboards every Monday. It is a real time signal. You are introducing autonomous work into the sales process.

835
00:52:00,300 --> 00:52:09,300
This is where change management gets harder because you are asking people to trust the system with decisions they used to make themselves. But if the first two phases went well that trust is already there.

836
00:52:09,300 --> 00:52:24,300
The sellers have seen co pilot work they have seen the health scores develop accurately. They are ready to let the system take the first pass at qualification. Phase four is months 10 through 12. Optimization you have the full system running. Now you measure it. You look at the data to see which agents are actually effective.

837
00:52:24,300 --> 00:52:30,300
You track the KPIs to see which flows are generating the most value. Look at your cycle time your win rate and your deal size.

838
00:52:30,300 --> 00:52:40,300
If those are improving you have your evidence if they are not you debug the process are the agents missing the right signals are the flows routing leads to the wrong people are the sellers just ignoring what the system recommends.

839
00:52:40,300 --> 00:52:59,300
You refine everything based on the outcomes you adjust the agent prompts you improve the orchestration logic then you expand the agents to other use cases if the research agent works for new business try using it for renewals and expansion the system materials because you iterate on it each phase deliver something real you aren't building in the dark and waiting for a final product.

840
00:52:59,300 --> 00:53:14,300
You are delivering value in increments you are earning credibility you are building muscle in the team by the time you reach phase four the system is operating at scale because you took nine months to make it work you didn't rush you didn't cut corners you just made steady progress that is how you actually implement this.

841
00:53:14,300 --> 00:53:24,300
The governance challenge by phase four you have a real system running multiple agents are making decisions copilot is synthesizing intelligence across thousands of interactions every single day.

842
00:53:24,300 --> 00:53:47,300
The automatic flows are routing leads and escalating accounts the volume is high and this is when you discover the thing nobody warns you about autonomous systems at scale require constant oversight it is not that agents are dangerous they aren't but when you have dozens of agents making thousands of micro decisions every day you need to see what they are doing you need to know if one of them starts acting strange you have to catch those problems before they cascade through the system.

843
00:53:47,300 --> 00:54:16,300
The name work starts with an inventory you have to know which agents exist in your organization that seems obvious but it usually isn't in companies without discipline agents just proliferate one team builds a research agent another team builds a qualification agent for their specific segment someone in operations builds a churn detection agent they all live in different co pilot studio environments they use different data they use different naming conventions nobody has a central registry when something breaks nobody even knows what depends on it a centralized agent inventory changes that you need a registry that lists every day.

844
00:54:16,300 --> 00:54:45,300
The registry that lists every agent in production it shows who owns it what it does and what data it connects to this becomes your single source of truth it doesn't have to be complicated a spreadsheet works just fine what matters is that the information exists in one place and stays current change control is where governance becomes real before an agent goes into production someone has to review it this isn't just a technical check to see if it crashes it is a business review does this agent respect our data policies does it align with how we want to sell does it make decisions that match our values if a research agent overweight company size and ignores growth stage.

845
00:54:45,300 --> 00:55:14,300
It might root high growth startups away from your enterprise team that is a governance failure you have to catch that before the agent touches a real opportunity monitoring is the part that never stops you need telemetry on every agent you have running how many leads did it process this week what percentage to the qualified versus reject what do the confidence scores look like when the qualification accuracy drops that is your signal it means something changed maybe the underlying model drifted maybe the data quality got worse maybe the market changed and the agent is looking for the wrong things the metrics tell you there is a problem.

846
00:55:14,300 --> 00:55:43,300
So you can go investigate it incident response is your emergency process when an agent goes wrong and they will go wrong eventually you need a documented way to handle it does the agent have a circuit breaker can you pause it quickly if it starts making bad calls can you roll back to the version that worked you need to be able to isolate it so it stops processing work while you fix the issue these processes stop a single mistake from corrupting your entire database order trails are just as important every decision an agent makes needs to be locked you don't just log the outcome you log the reasoning the confidence is not going to be a little bit more difficult to do.

847
00:55:43,300 --> 00:56:12,300
So the reasoning the confidence score and the data the agent was looking at this creates a complete record when something fails you can replay the event you can see exactly what the agent saw and why it made that choice you can tell if the error was in the logic or in the data your governance should match how your organization already works if your company has rules for how humans make decisions the agents should follow those same patterns if a salesperson has to document why they disqualified an account the agent should do the same thing if managers review human decisions once a month they should review agent decisions too.

848
00:56:12,300 --> 00:56:40,300
Consistency is what builds trust this isn't about putting handcuffs on your agents it is the opposite governance is what makes agents trust worthy when you can prove that a decision is documented and reversible people will actually use the system when governance is missing agents become black boxes people stop trusting them they stop using them and then all that investment in automation just gets abandoned the reality is clear governance is not overhead it is the foundation that lets you operate at scale without it you are just hoping for the best with it you actually know what is happening the sellers changing the

849
00:56:40,300 --> 00:57:08,300
governance keeps the system honest but there is a deeper question underneath all of this as the automation handles more of the work what actually happens to the people doing the selling the honest answer is that their job transforms it doesn't disappear but it changes fundamentally in the old model sellers were multiple hats they researched prospects by digging through linked in and company websites and news articles to understand who they were talking to they gathered information and spent hours on research before moving data around logging activities into the CRM and updating fields

850
00:57:08,300 --> 00:57:32,300
they created follow-up tasks and responded to admin overhead then if time remained they actually sold they had conversations they built relationships they moved deals forward the research had and the administrative had consumed enormous time studies show that sellers spend 70% of their day on non selling activities 70% research data entry CRM maintenance internal meetings and administrative overhead take up the bulk of their schedule

851
00:57:32,300 --> 00:57:48,300
and then somehow they were expected to close deals with the 30% of time remaining in the new model agents and automation handle the research they handle the data entry they manage the administrative overhead what remains is the work that actually matters relationship building deal making strategy

852
00:57:48,300 --> 00:58:00,300
this doesn't mean the seller role shrinks it means the role transforms the seller becomes four things instead of one first a relationship steward this is the core of selling it is about understanding what a customer actually needs and building trust through conversations

853
00:58:00,300 --> 00:58:16,300
where you listen more than you talk showing the customer that you understand their world is a skill that cannot be automated an agent cannot build a relationship because only a human can do that the agent prepares the groundwork by researching the company identifying the buying committee and understanding the competitive landscape

854
00:58:16,300 --> 00:58:28,300
the seller walks in knowing all of that then the seller does what only a seller can do which is to connect with the person across the table they find common ground and make the customer feel understood that is stewardship that is the foundation

855
00:58:28,300 --> 00:58:46,300
and a strategic advisor customers do not want sales people who just pitch products they want advisors who help them think when you understand what a customer is trying to accomplish your job is to help them think through the options what is the best approach what are the risks where have we seen this go wrong where have we seen it go right this requires judgment and wisdom

856
00:58:46,300 --> 00:58:54,300
it is the kind of insight that comes from seeing hundreds of situations and understanding patterns agents can provide information but they cannot provide wisdom the seller does that

857
00:58:54,300 --> 00:59:15,300
the real deal maker after all the relationship building and strategic advising someone has to close someone has to negotiate someone has to handle the moment when the customer hesitates and you need to understand why is it price is it uncertainty about implementation is it organizational politics inside their company the seller navigates that the agent prepared everything but the seller closes it that is a different skill

858
00:59:15,300 --> 00:59:44,300
the agent manager this is new sellers are becoming supervisors of AI an agent brings the list of qualified leads and the sellers job is to direct it they focus on specific accounts first and deprioritize others they might tell the agent to spend more research time on a certain segment the seller becomes the one who makes sure the automation is pointed in the right direction they interpret the agents output and judge whether the recommendations make sense they know when to trust the agent and when to override it that is management the time freed up by automation is the opportunity

859
00:59:44,300 --> 01:00:13,300
the seller who uses that time to deepen relationships will outperform someone who uses it to handle more transactions the bar moves the capability ceiling rises speed matters less quality of relationship matters more the skill shift is substantial sellers need to be comfortable with AI not technically proficient just comfortable they need to know what agents can and cannot do they need to interpret recommendations critically they need to know when an agent is right and when it is missing something human see immediately the compensation model probably needs to rethink itself too

860
01:00:13,300 --> 01:00:41,300
the prospecting activity based compensation does not make sense anymore you cannot measure a seller by dials or emails when an agent is doing that work outcome metrics matter more did you close the deal what was the deal size how long did it take what is the customer satisfaction these become the measures organizations that manage this transition cleanly will see real productivity gains those that ignore the change will see sellers ignoring the system confused about their role and doing the old work in new tools the role itself is solid the transition is the hard part

861
01:00:41,300 --> 01:01:09,300
organizational implications the traditional sales hierarchy assumes a specific shape sdr prospect a s close managers over the activity the structure is built around the assumption that humans do the prospecting and qualification work that assumption is now broken when agents handle prospecting the sdr role becomes a decision point some organizations will eliminate it entirely why hire someone to research prospects when an agent does it for free the work that justify the role no longer exists

862
01:01:09,300 --> 01:01:25,300
organizations will evolve the role the sdr becomes an agent manager they do not research prospects themselves they direct agents were to focus they refine agent prompts based on what the market is telling them they handle the accounts that the agent flagged as complex or borderline there is still a human in the process but they are doing different work

863
01:01:25,300 --> 01:01:53,300
a third path is specialization instead of generalist sdr's you hire specialists one person focuses on account research while another focuses on competitive intelligence a third person handles buying committee mapping agents do prospecting volume but specialists do depth the sdr role does not disappear but it transforms into a portfolio of specialized functions the a roll shifts in a different direction a is no longer spend time prospecting for opportunities because the agent's surface those a is focus on complex deals and key accounts

864
01:01:53,300 --> 01:02:21,300
their job is to take what the agent qualified and move it forward the qualification might be solid the prospect fits the buying signal is real and the timing is good but closing a complex deal requires human judgment it requires understanding organizational politics it requires negotiating when the customer wants terms you cannot give it requires judgment about when to escalate when to walk away and when to bring in other resources these are things agents cannot do a is become premium resources deployed against the deals that matter most

865
01:02:21,300 --> 01:02:39,300
management shifts in parallel sales managers stop obsessing over activity metrics like calls made emails sent and meetings booked those metrics do not matter anymore when agents handle volume managers focus on coaching if a seller just lost a deal the managers job is to understand why and help them think through what would have worked differently if a team

866
01:02:39,300 --> 01:03:03,300
is faster than the industry average the managers job is to understand the pattern and teacher to others if a seller is struggling with a specific customer type the manager's job is to help them see what they are missing activity management becomes strategy coaching the organizational structure itself might flatten if agents handle routine prospecting and qualification you need fewer layers between front line sellers and leadership the structure compresses or it might specialize instead

867
01:03:03,300 --> 01:03:22,300
rather than geography based territories or company size based segments you organize by use case one division handles new business while another handles expansion in existing accounts a third division handles renewals each division has sellers optimized for that motion agents handle discovery and qualification across all three and humans specialize in what matters to each division

868
01:03:22,300 --> 01:03:51,300
the key inside is this organizational structure should reflect the work that actually needs doing if agents to prospecting do not keep STR head count if a is do not do research do not spend their time on it if managers are not counting activities do not measure them the structure should align with where human value is created this is not a one time reorganization as agents become more capable the organization will evolve again maybe in two years agents can handle early negotiation which changes the a roll further maybe they can handle relationship maintenance on renewal deals which changes how you staff that segment

869
01:03:51,300 --> 01:04:13,300
the structure that works today will not work in 18 months the competitive advantage goes to organizations that adapt quickly those that cling to old structures by keeping STRs doing work agents do better measuring sellers on activities agents handle and organizing by geography when agents have already researched the target accounts will lag behind they are paying for work that does not need to exist anymore

870
01:04:13,300 --> 01:04:26,300
the next frontier multi agent B to B everything we've covered so far assumes your sales agents are only on one side of the table your organization builds agents to research prospects to qualify leads to prepare opportunities

871
01:04:26,300 --> 01:04:37,300
but the person on the other side the buyer is still a human being your agent informs your seller your seller persuades the buyer that assumption is about to break the next shift in this architecture is multi agent B to B

872
01:04:37,300 --> 01:04:54,300
it's your agents negotiating with buyer agents it isn't your seller talking to their buyer anymore it's your algorithm talking to their algorithm gardener predicts that by 2028 90% of B to B purchases will be mediated by AI agents think about that number for a second it's not that AI touches the transaction at some point

873
01:04:54,300 --> 01:05:06,300
it's that agents are mediating the entire process agents making the actual buying decision agents negotiating the terms agents closing the deals this isn't a hypothetical future early versions of buyer agents are already running in the wild

874
01:05:06,300 --> 01:05:35,300
companies like Cooper and Arriba are building them right now these agents live inside procurement departments when a company needs to buy software licenses or cloud infrastructure the buyer agent steps in it already understands the budget constraints it knows the approved vendors it knows the preferred terms it can evaluate proposals and make buying decisions on its own or with almost no human help when that world becomes the standard everything changes your sales agent can't win by doing what it does today right now it's trying to persuade a human it looks for emotional hooks it tries to appeal to a person's values and goals

875
01:05:35,300 --> 01:05:55,300
but all of that is irrelevant when the buyer isn't a person a buyer agent doesn't care about your story it cares about parameters price delivery timelines feature sets compliance the buyer agent has a scorecard every vendor gets rated against that scorecard the winner is simply the one that scores highest within the company's constraints your sales agent has to understand that logic

876
01:05:55,300 --> 01:06:24,300
it has to know what the buyer agent is optimizing for if the buyer agent gives you an eight out of ten on cost what specific change would push you to a nine what would drop you to a seven these are the only questions that matter now the negotiation shifts entirely it's no longer let me tell you why we're better it becomes I see your optimizing for speed and compliance the conversation is analytical not persuasive its optimization not selling your agents still needs to negotiate but it looks different the buyer agent might send back a counter proposal your agent has to evaluate it instantly

877
01:06:24,300 --> 01:06:44,300
not just against your profit targets but against what your company can actually deliver can you hit that timeline without breaking your quality standards can you bundle services to meet their cost cap can you suggest an alternative that scores better for them then their own original request escalation becomes the new safety valve some deals will be too messy for agent to agent talk there might be stakeholders with conflicting priorities

878
01:06:44,300 --> 01:07:08,300
or a deal that needs custom work outside your standard model your agent has to recognize these moments it needs to escalate to a human at the right time not too early because that was time but exactly when it's hit the limit of its logic the sales playbook is being rewritten instead of building rapport its understanding parameters instead of telling a story it's providing transparent data instead of overcoming objections it's solving constraints

879
01:07:08,300 --> 01:07:37,300
this requires you to prepare your foundation now you have to test your agent against buyer agent logic you have to define which deals it can close alone and which ones need a human hand you need guardrails what's your absolute floor on margin what delivery dates are actually possible organizations building this foundation today will have a massive lead if you wait until buyer agents are everywhere you're already behind the time to start thinking about agent to agent negotiation is right now building the foundation for what's next multi agent B to B isn't some distant idea it's a direction with a dead

880
01:07:37,300 --> 01:08:06,300
the company's that will win in that world aren't the ones who start when the buyer agents show up they're the ones who started building the infrastructure years ago the good news is you don't have to predict the exact future to get ready you just need a foundation that's flexible enough to adapt the architecture we've talked about today isn't just for current problems it's the substrate that makes future problems solvable that foundation relies on three things that compound each other if you miss one the other two only work half as well the first is data integration every piece of customer data has to flow into a central system like dynamics three

881
01:08:06,300 --> 01:08:20,300
65 not just the easy data all of it linked in signals email threads core recordings usage data support tickets when a buyer agent evaluates you against the scorecard your agent needs to pull from every dimension of that relationship

882
01:08:20,300 --> 01:08:31,300
it can only do that if the data is in one place and ready to be queried if your data is fragmented some in CRM some in spreadsheets some in people's heads your agent will have massive reasoning gaps

883
01:08:31,300 --> 01:09:00,300
the second is a already architecture this means designing your systems assuming agents will be the ones using them systems built for humans look like dashboards and forms systems built for agents look like apis and structured data if you build a dynamics environment where everything is locked in custom UI forms agents can't interact with it but if you structure your decisions and activities in data verse with clear schemas agents can reason about the data and act immediately the design choice you make today determines if an agent can even function in two years the third is governance by default

884
01:09:00,300 --> 01:09:13,300
this isn't something you bolt on after a problem happens it's built into the design from day one you need access controls that know which agents can see which files you need audit trails that capture every decision automatically you need logging that explains not just what happened

885
01:09:13,300 --> 01:09:24,300
but why the system did it companies that treat governance as an afterthought spend years fixing it later companies that build it in from the start don't have that debt the architecture already knows how to explain itself to a regulator

886
01:09:24,300 --> 01:09:41,300
these three things integration architecture and governance aren't separate they reinforce each other good integration makes agents smarter clean architecture makes governance easier to run built in governance makes the whole system trustworthy which leads to better data which leads to better reasoning the takeaway is simple start now

887
01:09:41,300 --> 01:09:50,300
not because every part of multi agent B2B is ready today but because the foundation takes time to build the organizations already building it are gaining an advantage every single month

888
01:09:50,300 --> 01:10:06,300
while everyone else is waiting they're compounding their lead if this changed how you think about the future of sales follow me my competitors on LinkedIn and if you want more of this leave a review it helps more people find the show share this with your team especially if you are looking at your AI strategy right now

889
01:10:06,300 --> 01:10:13,300
the risks you need to know building the foundation is necessary but foundation building without clear I'd risk awareness produces brittle systems

890
01:10:13,300 --> 01:10:30,300
the risks here aren't theoretical edge cases they are documented failure modes and organizations are already encountering them as they deploy this architecture at scale algorithmic bias is the first one most people don't see coming agents learn from historical data if your sales records show that senior sellers always got the big accounts

891
01:10:30,300 --> 01:10:40,300
while junior sellers took the rest the agent will replicate that patent it doesn't know that the patent reflects historical bias rather than strategic intent it sees a correlation and then it acts on it

892
01:10:40,300 --> 01:10:50,300
the result is a system that systematically disadvantages certain prospect types or demographics this doesn't happen because anyone intended it it happens because the data sets or the mitigation is deliberate

893
01:10:50,300 --> 01:10:56,300
you have to audit your training data before you build agents on top of it understand what patterns are embedded in your historical records

894
01:10:56,300 --> 01:11:02,300
if the pattern reflects a bias you want to correct correct it before the agent learns it hallucination is the second risk

895
01:11:02,300 --> 01:11:14,300
copilot in agents are language models at their core language models generate plausible sounding output when the underlying data is ambiguous or incomplete they can generate output that sounds authoritative but is factually wrong

896
01:11:14,300 --> 01:11:27,300
a meeting prep brief might describe a prospect as operating in a market they exit it two years ago a relationship health summary might say engagement is strong when the last real interaction was six months ago a lead score might reflect a model's confidence not actual fit

897
01:11:27,300 --> 01:11:46,300
sellers who trust these outputs uncritically can make decisions based on wrong information the mitigation is a culture of critical engagement sellers need to treat agent outputs as hypotheses to verify not facts to act on the system needs prominent uncertainty indicators like confidence scores and data freshness timestamps this ensures sellers know when to double check before acting

898
01:11:46,300 --> 01:11:54,300
over reliance follows from hallucination if you're not careful when agents perform well consistently sellers stop questioning them they execute recommendations without thinking

899
01:11:54,300 --> 01:12:12,300
the agents says call this person today they call the agents says deprioritize this account they deprioritize that uncritical trust is dangerous because agents fail in ways humans don't anticipate the failure isn't dramatic it's quiet it is a slow drift in recommendation quality that goes unnoticed because nobody is checking the mitigation is embedding human

900
01:12:12,300 --> 01:12:28,300
review into the process even when the agent is performing well you need regular spot checks managers should pull a sample of agent decisions and evaluate them independently keep sellers sharp by requiring them to articulate why they're following a recommendation data privacy risk scales as agents access more the intelligence

901
01:12:28,300 --> 01:12:39,300
layer touches emails calls and meeting transcripts that breadth of access is what makes the reasoning powerful it's also what makes governance essential every new data source an agent can access is a new surface area for exposure

902
01:12:39,300 --> 01:12:51,300
when an agent can read email threads it might surface a message that contains sensitive client information the seller didn't intend to share when an agent can access call transcripts it processes potentially confidential conversations

903
01:12:51,300 --> 01:13:05,300
the mitigation is role-based access that applies as strictly to agents as to humans an agent shouldn't see data its human counterpart isn't authorized to see regulatory risk compounds when agents make decisions at scale a single discriminatory decision by a human is an isolated incident

904
01:13:05,300 --> 01:13:14,300
the same pattern embedded in an agent runs at volume thousands of decisions reflecting that pattern happened before anyone notices that's regulatory exposure

905
01:13:14,300 --> 01:13:21,300
intelligent monitoring is what catches these patterns early you must track decision distributions across demographic and firmographic dimensions

906
01:13:21,300 --> 01:13:31,300
vendor lock-in is quieter but equally consequential an architecture built entirely on dynamics 365 and co-pilot is an architecture that becomes expensive to change features

907
01:13:31,300 --> 01:13:45,300
data schemas and agent logic all get embedded in Microsoft's ecosystem when Microsoft changes pricing or evolves the platform in ways that don't suit your needs the cost of moving is enormous design with portability in mind from the beginning use clean data models use abstracted integration layers

908
01:13:45,300 --> 01:13:54,300
built agent logic that could be ported if necessary change management failure is perhaps the most preventable risk if sellers don't trust the system they ignore it

909
01:13:54,300 --> 01:14:07,300
all the architecture in the world doesn't produce results if the people it's designed to help won't use it trust gets built through demonstrated accuracy over time start with high visibility wins let sellers see the system get it right before you ask them to depend on it

910
01:14:07,300 --> 01:14:16,300
your CRM was blind without LinkedIn your LinkedIn account was isolated without dynamics 365 the unified system extraction reasoning action closes that gap

911
01:14:16,300 --> 01:14:33,300
it turns to half pictures into one coherent view of every relationship that matters to your business this isn't a product release it's a structural shift in how sales organizations operate the organizations building this foundation now won't need to scramble when buyer agents arrive they will be ready when the market moves at machine speed

912
01:14:33,300 --> 01:14:42,300
if this episode changed how you think about the architecture of modern selling follow me my competitors on LinkedIn and if you want more of this subscribe for more