WEBVTT

1
00:00:00.080 --> 00:00:03.040
<v Speaker 1>Okay, let's unpack this one. Yeah, today we're diving into

2
00:00:03.080 --> 00:00:07.719
<v Speaker 1>something pretty interesting. It's excerpts from a book Force dot

3
00:00:07.719 --> 00:00:12.400
<v Speaker 1>Com Development Blueprints from back in twenty fourteen.

4
00:00:12.119 --> 00:00:15.599
<v Speaker 2>Right, twenty fourteen, so like a decade ago now roughly exactly.

5
00:00:15.679 --> 00:00:17.399
<v Speaker 1>It's kind of like hitting the way of back machine,

6
00:00:17.760 --> 00:00:22.000
<v Speaker 1>you know, seeing how experienced developers were building some pretty

7
00:00:22.000 --> 00:00:25.239
<v Speaker 1>sophisticated applications on the Force dot Com platform back then.

8
00:00:27.239 --> 00:00:30.960
<v Speaker 1>So our goal, our mission for this deep dive, it's

9
00:00:31.000 --> 00:00:33.640
<v Speaker 1>really to pull out those core blueprints, those patterns.

10
00:00:33.359 --> 00:00:35.840
<v Speaker 2>Yeah, the essential ideas, the how to from that era.

11
00:00:35.759 --> 00:00:37.960
<v Speaker 1>And figure out, okay, why did this stuff matter back then?

12
00:00:38.719 --> 00:00:43.280
<v Speaker 1>And importantly for you listening, what enduring value is there?

13
00:00:43.520 --> 00:00:45.479
<v Speaker 1>What can we still learn from it today? Does it

14
00:00:45.520 --> 00:00:46.119
<v Speaker 1>still hold up?

15
00:00:46.200 --> 00:00:48.439
<v Speaker 2>That's right? And we're grounding this whole discussion in this

16
00:00:48.560 --> 00:00:51.119
<v Speaker 2>packbook by Steven Moss. This guy, Stephen, he was a

17
00:00:51.159 --> 00:00:55.240
<v Speaker 2>Force dot Com developer, certified admin to with like over

18
00:00:55.320 --> 00:00:56.359
<v Speaker 2>twenty years in it.

19
00:00:56.799 --> 00:00:59.200
<v Speaker 1>Wow, twenty years even back then, Yeah.

20
00:00:59.039 --> 00:01:02.399
<v Speaker 2>Going way back. He programmed on a Commodore sixty four

21
00:01:03.399 --> 00:01:06.560
<v Speaker 2>and his background was super diverse. CRM sure, but also

22
00:01:06.879 --> 00:01:11.599
<v Speaker 2>gis manufacturing even early mobile dev the book mentions he

23
00:01:11.719 --> 00:01:12.959
<v Speaker 2>still had a palm pilot.

24
00:01:13.359 --> 00:01:17.200
<v Speaker 1>Sleigh chuckle, a palm pilot. Yeah, that really paints a

25
00:01:17.200 --> 00:01:19.000
<v Speaker 1>picture of the tech landscape, then, doesn't it.

26
00:01:19.000 --> 00:01:22.519
<v Speaker 2>It absolutely does. And importantly, this wasn't just you know,

27
00:01:22.599 --> 00:01:26.040
<v Speaker 2>one guy's opinion. The book had several experience reviewers too,

28
00:01:26.159 --> 00:01:30.840
<v Speaker 2>people with deep backgrounds in Salesforce, architecture, consulting various IT fields.

29
00:01:30.920 --> 00:01:34.000
<v Speaker 1>Okay, so it's grounded in real world practice, not just.

30
00:01:34.000 --> 00:01:38.239
<v Speaker 2>Theory, exactly practical hands on experience from that time. And yeah,

31
00:01:38.280 --> 00:01:41.079
<v Speaker 2>the specific versions of sales coorse features they're from twenty fourteen.

32
00:01:41.760 --> 00:01:46.200
<v Speaker 2>But the underlying approach, how they use the platform's building blocks, objects, code,

33
00:01:46.239 --> 00:01:49.200
<v Speaker 2>integration points, that's what's really insightful, I think.

34
00:01:49.359 --> 00:01:51.400
<v Speaker 1>Right, So let's dive into that first blueprint the book

35
00:01:51.480 --> 00:01:54.840
<v Speaker 1>lays out. It tackles a pretty fundamental challenge, how do

36
00:01:54.920 --> 00:01:58.680
<v Speaker 1>you build those external facing websites or maybe communities that

37
00:01:58.719 --> 00:02:01.799
<v Speaker 1>are tightly integrated with through Force dot com data.

38
00:02:01.920 --> 00:02:05.000
<v Speaker 2>Right, And this blueprint it really leverages what were key

39
00:02:05.040 --> 00:02:08.800
<v Speaker 2>features for this back then, communities Incite dot com. The

40
00:02:08.919 --> 00:02:12.759
<v Speaker 2>main idea was using these native platform tools, you could

41
00:02:12.759 --> 00:02:17.319
<v Speaker 2>expose you know, select Force dot com data and processes

42
00:02:17.319 --> 00:02:19.159
<v Speaker 2>to people outside.

43
00:02:18.479 --> 00:02:22.080
<v Speaker 1>Your org without needing a whole separate database or tons

44
00:02:22.120 --> 00:02:23.319
<v Speaker 1>of complex infrastructure.

45
00:02:23.360 --> 00:02:25.400
<v Speaker 2>Right exactly. It simplified things quite a bit.

46
00:02:25.680 --> 00:02:28.120
<v Speaker 1>And the book walks through a specific example setting up

47
00:02:28.120 --> 00:02:31.599
<v Speaker 1>this Force Volunteers community. So sorts of the basics the setup.

48
00:02:32.240 --> 00:02:35.360
<v Speaker 1>Get to enable communities in your org the first that,

49
00:02:35.520 --> 00:02:38.840
<v Speaker 1>and create the specific community instance itself to find the

50
00:02:38.840 --> 00:02:42.159
<v Speaker 1>Force dot Com objects they'll interact with, like the use

51
00:02:42.199 --> 00:02:44.319
<v Speaker 1>of volunteer event custom object.

52
00:02:44.000 --> 00:02:46.080
<v Speaker 2>Example, right, the data structure underneath, and.

53
00:02:46.000 --> 00:02:49.199
<v Speaker 1>Then crucial details like setting up specific user profiles they

54
00:02:49.240 --> 00:02:52.680
<v Speaker 1>mentioned a volunteer community user profile and getting those permissions

55
00:02:52.960 --> 00:02:57.680
<v Speaker 1>just right often read only access to things like accounts, contacts,

56
00:02:57.800 --> 00:02:59.159
<v Speaker 1>and those volunteer events.

57
00:02:59.439 --> 00:03:02.120
<v Speaker 2>Yeah, that's set up. Part is critical. It defines the

58
00:03:02.199 --> 00:03:04.759
<v Speaker 2>data model and exactly who gets to see what. But

59
00:03:04.840 --> 00:03:07.080
<v Speaker 2>the really interesting bit, I think is how they actually

60
00:03:07.080 --> 00:03:09.800
<v Speaker 2>built the look and feel of the public site. Okay,

61
00:03:09.919 --> 00:03:13.879
<v Speaker 2>the blueprint uses site dot com Studio, which was this

62
00:03:15.000 --> 00:03:18.520
<v Speaker 2>visual design tool. Think of it like well, kind of

63
00:03:18.560 --> 00:03:21.120
<v Speaker 2>a precursor to modern drag and drop.

64
00:03:21.360 --> 00:03:23.719
<v Speaker 1>Builders made a visual page building.

65
00:03:23.520 --> 00:03:26.680
<v Speaker 2>Yeah, letting you assemble pages using components things like header

66
00:03:26.719 --> 00:03:30.479
<v Speaker 2>and footer widgets. You could manage assets like images, logos

67
00:03:30.560 --> 00:03:34.520
<v Speaker 2>right there in Salesforce, and you could customize the branding visually,

68
00:03:35.000 --> 00:03:38.680
<v Speaker 2>down to setting color schemes with like HDML color codes.

69
00:03:38.800 --> 00:03:41.719
<v Speaker 1>Right. But it wasn't just about making static pages look nice.

70
00:03:41.919 --> 00:03:45.439
<v Speaker 1>The real power came from embedding live data. Yeah, totally.

71
00:03:45.520 --> 00:03:48.520
<v Speaker 2>The blueprint shows how you could like drag a data

72
00:03:48.560 --> 00:03:51.400
<v Speaker 2>table component onto an events page, point it at that

73
00:03:51.479 --> 00:03:53.560
<v Speaker 2>volunteer event custom object you set.

74
00:03:53.400 --> 00:03:55.439
<v Speaker 1>Up, and boom, there's your list of events.

75
00:03:55.240 --> 00:03:58.560
<v Speaker 2>Exactly, pulled straight from your Salesforce data live. And you

76
00:03:58.560 --> 00:04:02.280
<v Speaker 2>could configure filtering as ordering right thereinthsite dot com editor

77
00:04:02.400 --> 00:04:05.639
<v Speaker 2>like show events sorted by start day, ascending order that

78
00:04:05.759 --> 00:04:08.680
<v Speaker 2>kind of thing. Ic and security making sure only the

79
00:04:08.759 --> 00:04:10.000
<v Speaker 2>right people see certain.

80
00:04:09.759 --> 00:04:12.520
<v Speaker 1>Pages, yeah, that was handled too. You could secure pages

81
00:04:12.560 --> 00:04:16.000
<v Speaker 1>with a simple setting. The book mentions a padlock icon

82
00:04:16.000 --> 00:04:21.079
<v Speaker 1>appearing so certain content only visible to logged in community members.

83
00:04:21.720 --> 00:04:25.759
<v Speaker 1>You could even add personalized elements like maybe a chatterfeed

84
00:04:25.839 --> 00:04:29.199
<v Speaker 1>showing stuff relevant to the logged in volunteer on their

85
00:04:29.199 --> 00:04:30.120
<v Speaker 1>profile page.

86
00:04:30.240 --> 00:04:33.639
<v Speaker 2>So the big takeaway from this first blueprint it's really

87
00:04:33.639 --> 00:04:37.319
<v Speaker 2>that even a decade ago, the platform offered these pretty

88
00:04:37.439 --> 00:04:40.800
<v Speaker 2>robust built in tools, tools that let you go from

89
00:04:40.839 --> 00:04:44.279
<v Speaker 2>just an internal data model to a full on, branded,

90
00:04:44.519 --> 00:04:48.439
<v Speaker 2>data driven external site with user management security.

91
00:04:48.920 --> 00:04:51.600
<v Speaker 1>Yeah, and it's significantly lowered the barrier to entry, didn't

92
00:04:51.600 --> 00:04:55.079
<v Speaker 1>it compared to building all that from scratch with traditional webstacks.

93
00:04:55.360 --> 00:04:57.399
<v Speaker 1>Abstracted away a lot of the back end headache.

94
00:04:57.439 --> 00:04:59.800
<v Speaker 2>That's a great point. Okay, shifting gears now completely different,

95
00:04:59.800 --> 00:05:02.160
<v Speaker 2>direc The sources also lay out a blueprint for an

96
00:05:02.199 --> 00:05:06.199
<v Speaker 2>e commerce solution. But this isn't just building order forms

97
00:05:06.199 --> 00:05:07.120
<v Speaker 2>inside Salesforce.

98
00:05:07.240 --> 00:05:09.160
<v Speaker 1>No, this is different. This is about using Force dot

99
00:05:09.160 --> 00:05:12.639
<v Speaker 1>com as the back end system for an external online store.

100
00:05:13.040 --> 00:05:16.839
<v Speaker 2>And they use a fun example, a fictional company selling

101
00:05:16.920 --> 00:05:19.600
<v Speaker 2>like high performance racing car engines.

102
00:05:19.759 --> 00:05:20.199
<v Speaker 1>Nice.

103
00:05:20.720 --> 00:05:24.759
<v Speaker 2>The approach starts, you know where it usually does, defining

104
00:05:24.800 --> 00:05:28.519
<v Speaker 2>the data model within Force dot com. So custom objects

105
00:05:28.600 --> 00:05:31.399
<v Speaker 2>like order orderline item maybe for the engine types, and

106
00:05:31.560 --> 00:05:33.480
<v Speaker 2>order line for these specific items in a.

107
00:05:33.439 --> 00:05:36.199
<v Speaker 1>Particular order, right the core data structure.

108
00:05:35.920 --> 00:05:38.920
<v Speaker 2>And the blueprint gets pretty specific about configuring the fields,

109
00:05:39.319 --> 00:05:43.160
<v Speaker 2>setting up the right field types, number, picklist, currency, and

110
00:05:43.240 --> 00:05:47.319
<v Speaker 2>defining the relationships like lookups or master detail between these objects.

111
00:05:47.560 --> 00:05:50.480
<v Speaker 1>Now, why is that level of detail on field types

112
00:05:50.519 --> 00:05:54.000
<v Speaker 1>and names so critical in this specific blueprint.

113
00:05:54.279 --> 00:05:56.920
<v Speaker 2>Ah, because the crucial piece here isn't just the Force

114
00:05:56.959 --> 00:06:00.480
<v Speaker 2>dot Com side, it's the integration. This whole solution depends

115
00:06:00.519 --> 00:06:03.759
<v Speaker 2>heavily on an external e commerce website talking to Salesforce,

116
00:06:04.079 --> 00:06:07.680
<v Speaker 2>and for that connection that API communication to work smoothly.

117
00:06:08.199 --> 00:06:11.199
<v Speaker 2>The data structure, the field types, even the exact field

118
00:06:11.319 --> 00:06:14.079
<v Speaker 2>names Inforce dot Com. They need to align precisely with

119
00:06:14.120 --> 00:06:16.720
<v Speaker 2>what the external application expects when it's sending or asking

120
00:06:16.759 --> 00:06:19.240
<v Speaker 2>for data. Any mismatch causes problems.

121
00:06:19.519 --> 00:06:23.959
<v Speaker 1>Ah, got it, That makes perfect sense. So this external site,

122
00:06:24.480 --> 00:06:26.680
<v Speaker 1>where does it live? What's powering it?

123
00:06:27.040 --> 00:06:30.439
<v Speaker 2>This is where Heroku comes into the picture. Remember, Salesforce

124
00:06:30.439 --> 00:06:33.480
<v Speaker 2>had acquired Heroku a few years before twenty fourteen. So

125
00:06:33.560 --> 00:06:36.759
<v Speaker 2>the book highlights Heroku as the platform for hosting this

126
00:06:36.839 --> 00:06:41.040
<v Speaker 2>external store, okay, and it emphasizes Heroku's polyglot nature, you know,

127
00:06:41.079 --> 00:06:43.759
<v Speaker 2>its ability to run apps written in different languages like

128
00:06:43.879 --> 00:06:48.720
<v Speaker 2>Ruby on Rails, Java, no JS, Python gives developers flexidadity.

129
00:06:49.000 --> 00:06:51.600
<v Speaker 1>So the blueprint details setting up that dev environment like

130
00:06:51.639 --> 00:06:53.600
<v Speaker 1>installing node Rubyon, Rails.

131
00:06:53.399 --> 00:06:57.000
<v Speaker 2>Yep exactly, mentions minimum versions, installing get and crucially, it

132
00:06:57.040 --> 00:07:00.319
<v Speaker 2>walks through configuring a Force dot Com remote act access

133
00:07:00.319 --> 00:07:01.279
<v Speaker 2>application in.

134
00:07:01.240 --> 00:07:04.360
<v Speaker 1>That remote access app. That's the key for the secure connection,

135
00:07:04.399 --> 00:07:07.000
<v Speaker 1>the handshake between Heroku and Forest dot Com.

136
00:07:07.040 --> 00:07:10.879
<v Speaker 2>Precisely, that's how the external Heroku app gets the owooth credentials.

137
00:07:10.879 --> 00:07:13.480
<v Speaker 2>It needs the consumer key and secret that lets it

138
00:07:13.480 --> 00:07:16.319
<v Speaker 2>connect securely to the Force dot Com API and actually

139
00:07:16.399 --> 00:07:18.199
<v Speaker 2>access the data, create records, et cetera.

140
00:07:18.399 --> 00:07:21.120
<v Speaker 1>Okay, and the example uses Ruby on Rails for the

141
00:07:21.199 --> 00:07:22.000
<v Speaker 1>external site.

142
00:07:22.120 --> 00:07:24.879
<v Speaker 2>Yeah, the example build is in Rails and it uses

143
00:07:24.879 --> 00:07:28.319
<v Speaker 2>a library called the Force dot rb rubygem. The book

144
00:07:28.360 --> 00:07:30.879
<v Speaker 2>describes it as a nice wrapper around the Force dot

145
00:07:30.879 --> 00:07:35.240
<v Speaker 2>Com rest API. Basically, it simplifies making those API calls

146
00:07:35.240 --> 00:07:37.839
<v Speaker 2>from Ruby to do things like create order records in

147
00:07:37.879 --> 00:07:40.480
<v Speaker 2>Salesforce or look up product info stored there.

148
00:07:40.720 --> 00:07:43.480
<v Speaker 1>So let's trace the flow. A customer goes to the

149
00:07:43.480 --> 00:07:45.879
<v Speaker 1>external site on Heroku. They place an order for a

150
00:07:45.959 --> 00:07:49.959
<v Speaker 1>racing engine. That Rails app uses the Force dot RBGM

151
00:07:50.000 --> 00:07:52.439
<v Speaker 1>and the off credentials to talk to the Force dot

152
00:07:52.480 --> 00:07:53.319
<v Speaker 1>Com rest.

153
00:07:53.160 --> 00:07:56.600
<v Speaker 2>API and creates the order order line item order line

154
00:07:56.600 --> 00:07:58.040
<v Speaker 2>records inside Salesforce.

155
00:07:58.199 --> 00:08:00.600
<v Speaker 1>Okay, so the order data lands Inforce dot Com. What

156
00:08:00.680 --> 00:08:01.959
<v Speaker 1>happens then? Who handles it?

157
00:08:02.120 --> 00:08:04.319
<v Speaker 2>Right? So? Now Force dot Com shifts into being the

158
00:08:04.319 --> 00:08:08.399
<v Speaker 2>fulfillment and management system. The blueprint includes building an internal

159
00:08:08.439 --> 00:08:12.800
<v Speaker 2>fulfillment application within Force dot com itself using APEX controllers

160
00:08:12.800 --> 00:08:14.000
<v Speaker 2>and visual Force pages.

161
00:08:14.040 --> 00:08:16.560
<v Speaker 1>Ah, so internal users log into Salesforce exactly.

162
00:08:16.600 --> 00:08:18.759
<v Speaker 2>They log into this custom fulfillment app. They can search

163
00:08:18.800 --> 00:08:20.839
<v Speaker 2>for new orders that came in from the external site,

164
00:08:20.839 --> 00:08:24.680
<v Speaker 2>manage the order status, handle the shipping, the whole fulfillment process.

165
00:08:24.959 --> 00:08:30.040
<v Speaker 1>Gotcha. So the core insight here pretty powerful. This blueprint

166
00:08:30.160 --> 00:08:33.080
<v Speaker 1>really shows Force dot com not just as a place

167
00:08:33.120 --> 00:08:36.679
<v Speaker 1>to build apps, but as a kind of robust, secure

168
00:08:37.440 --> 00:08:40.399
<v Speaker 1>data hub and process engine for applications build anywhere else

169
00:08:40.759 --> 00:08:43.799
<v Speaker 1>on totally different textacts connected via APIs.

170
00:08:43.919 --> 00:08:47.159
<v Speaker 2>Yeah, and that pattern using Salesforce as a back end

171
00:08:47.200 --> 00:08:50.120
<v Speaker 2>service that's arguably even more relevant today, isn't it in

172
00:08:50.120 --> 00:08:52.600
<v Speaker 2>our whole micro services API first world?

173
00:08:52.759 --> 00:08:56.480
<v Speaker 1>Absolutely. It really demonstrates the platform's flexibility beyond just its

174
00:08:56.519 --> 00:08:59.399
<v Speaker 1>own native UI. Okay, let's pivot again. Let's go to

175
00:08:59.440 --> 00:09:02.960
<v Speaker 1>a more class CRM scenario. The sources give a detailed

176
00:09:02.960 --> 00:09:06.559
<v Speaker 1>blueprint for a student admission system for fictional Force University.

177
00:09:06.879 --> 00:09:10.080
<v Speaker 1>This sounds like building a comprehensive, process driven application entirely

178
00:09:10.120 --> 00:09:11.559
<v Speaker 1>within Force dot Com. Yeah.

179
00:09:11.720 --> 00:09:14.159
<v Speaker 2>This is a great example of building out complex business

180
00:09:14.159 --> 00:09:17.879
<v Speaker 2>logic using mostly native platform capabilities, and it starts as

181
00:09:17.919 --> 00:09:19.840
<v Speaker 2>you'd expect with a solid data model. You need to

182
00:09:19.879 --> 00:09:21.200
<v Speaker 2>track everything related.

183
00:09:20.879 --> 00:09:23.559
<v Speaker 1>To admissions, so custom objects.

184
00:09:23.080 --> 00:09:28.240
<v Speaker 2>Right, custom objects like course applicant and course application, and

185
00:09:28.320 --> 00:09:31.960
<v Speaker 2>they get into the field specifics again using dependent picklists,

186
00:09:31.960 --> 00:09:35.720
<v Speaker 2>maybe for course details. Marking certain applicant fields is required

187
00:09:35.879 --> 00:09:39.440
<v Speaker 2>given name, surname, date of birth, address.

188
00:09:39.320 --> 00:09:41.679
<v Speaker 1>All that core info, and probably a status field for

189
00:09:41.720 --> 00:09:42.759
<v Speaker 1>the application itself.

190
00:09:42.799 --> 00:09:46.559
<v Speaker 2>Definitely a picklist for application status on the course application

191
00:09:46.639 --> 00:09:51.399
<v Speaker 2>object with values tracking the whole life cycle new under assessment,

192
00:09:51.919 --> 00:09:55.919
<v Speaker 2>closed admit applicant, closed reject applicant, things like that.

193
00:09:55.759 --> 00:09:59.399
<v Speaker 1>Makes sense now beyond just storing the data the system,

194
00:09:59.440 --> 00:10:02.960
<v Speaker 1>like admission, it needs really careful management of who can

195
00:10:03.000 --> 00:10:06.200
<v Speaker 1>see what and how these applications actually move through the process.

196
00:10:06.279 --> 00:10:09.840
<v Speaker 2>Absolutely, access control and workflow automation are central here. The

197
00:10:09.879 --> 00:10:13.600
<v Speaker 2>blueprint outlines setting up different profiles, maybe one for course administration,

198
00:10:13.679 --> 00:10:16.639
<v Speaker 2>one for the admissions office staff, one for selection officers

199
00:10:16.639 --> 00:10:19.159
<v Speaker 2>who make the decisions, and also a role hierarchy that

200
00:10:19.200 --> 00:10:21.799
<v Speaker 2>mirrors the university structure, you know, president at the top

201
00:10:22.159 --> 00:10:24.600
<v Speaker 2>down through dean's managers, officers.

202
00:10:24.279 --> 00:10:27.559
<v Speaker 1>And that combination of profiles and roles lets you control

203
00:10:27.600 --> 00:10:28.840
<v Speaker 1>permissions very.

204
00:10:28.679 --> 00:10:33.720
<v Speaker 2>Granularly, exactly granular control over object access, field level security.

205
00:10:34.360 --> 00:10:37.600
<v Speaker 2>Making sure users only see and edit the data that's

206
00:10:37.639 --> 00:10:41.360
<v Speaker 2>relevant to their specific role in the whole admissions process,

207
00:10:41.440 --> 00:10:43.000
<v Speaker 2>keeps things secure and focused.

208
00:10:43.240 --> 00:10:46.559
<v Speaker 1>Okay, that covers access. What about the process automation? How

209
00:10:46.600 --> 00:10:50.960
<v Speaker 1>does an application automatically move from say new to under

210
00:10:51.000 --> 00:10:53.240
<v Speaker 1>assessment and get assigned to the right team or person.

211
00:10:53.480 --> 00:10:56.960
<v Speaker 2>Ah, this is where they combine configuration and code quite cleverly.

212
00:10:57.000 --> 00:11:01.480
<v Speaker 2>I thought the blueprint uses cues standard Salesforce cues OKA.

213
00:11:01.600 --> 00:11:04.960
<v Speaker 2>Maybe one queue for the business faculty admissions team, one

214
00:11:05.000 --> 00:11:08.399
<v Speaker 2>for the science faculty, perhaps an exception queue for applications

215
00:11:08.399 --> 00:11:11.840
<v Speaker 2>that need special handling. These cues act as holding bins

216
00:11:11.840 --> 00:11:12.720
<v Speaker 2>for the applications.

217
00:11:12.799 --> 00:11:14.879
<v Speaker 1>And how does the system know which queue to send

218
00:11:14.879 --> 00:11:17.360
<v Speaker 1>an application to based on the course they applied for?

219
00:11:17.639 --> 00:11:21.200
<v Speaker 2>Precisely? And they even suggest using custom settings remember those

220
00:11:21.559 --> 00:11:24.919
<v Speaker 2>to create a mapping. You'd map specific faculties or courses

221
00:11:24.960 --> 00:11:27.480
<v Speaker 2>to their corresponding quids in the custom settings.

222
00:11:27.759 --> 00:11:31.600
<v Speaker 1>Oh that's smart. So the routing destination becomes configurable without

223
00:11:31.639 --> 00:11:32.799
<v Speaker 1>needing to change code later.

224
00:11:32.960 --> 00:11:34.759
<v Speaker 2>Exactly makes it more maintainable.

225
00:11:35.080 --> 00:11:37.159
<v Speaker 1>So you set up the queues, you set up the

226
00:11:37.200 --> 00:11:41.960
<v Speaker 1>mapping and custom settings, but how does the system automatically

227
00:11:42.000 --> 00:11:45.120
<v Speaker 1>perform the routing when a new application comes in? What

228
00:11:45.200 --> 00:11:46.120
<v Speaker 1>triggers that?

229
00:11:46.120 --> 00:11:49.840
<v Speaker 2>That piece is handled by an APEX trigger. The blueprint

230
00:11:49.919 --> 00:11:53.600
<v Speaker 2>implements the core routing logic in a before insert trigger

231
00:11:53.679 --> 00:11:55.600
<v Speaker 2>on the course application object.

232
00:11:55.480 --> 00:11:58.039
<v Speaker 1>Before insert, so it fires before the new application record

233
00:11:58.080 --> 00:11:58.840
<v Speaker 1>is actually.

234
00:11:58.480 --> 00:12:02.200
<v Speaker 2>Saved yep, before it hits database. The trigger logic looks

235
00:12:02.240 --> 00:12:05.799
<v Speaker 2>at the course the applicant applied for it, queries those

236
00:12:05.840 --> 00:12:09.600
<v Speaker 2>custom settings to find the correct faculty QID based on

237
00:12:09.639 --> 00:12:10.399
<v Speaker 2>the mapping, and.

238
00:12:10.360 --> 00:12:12.639
<v Speaker 1>Then it sets the owner reed field on the new

239
00:12:12.679 --> 00:12:15.399
<v Speaker 1>course application record to that qid exactly.

240
00:12:15.480 --> 00:12:17.799
<v Speaker 2>So the moment the record is saved, it's already assigned

241
00:12:17.799 --> 00:12:19.840
<v Speaker 2>to the correct queue, ready for that team to pick

242
00:12:19.879 --> 00:12:20.159
<v Speaker 2>it up.

243
00:12:20.360 --> 00:12:23.720
<v Speaker 1>Wow, that's a really neat pattern. You're using clicksnot code

244
00:12:23.759 --> 00:12:27.559
<v Speaker 1>for the queues and the configurable mapping, but then a

245
00:12:27.919 --> 00:12:31.360
<v Speaker 1>targeted piece of APEX code for the dynamic routing logic

246
00:12:31.639 --> 00:12:35.559
<v Speaker 1>based on that configuration. That's a great aha moment showing

247
00:12:35.600 --> 00:12:40.360
<v Speaker 1>how those different platform tools work together. For pre sophisticated automation.

248
00:12:40.639 --> 00:12:42.879
<v Speaker 2>It really is, and they didn't stop just at routing.

249
00:12:43.120 --> 00:12:48.080
<v Speaker 2>The blueprint also included a user experience enhancement, a decision entry.

250
00:12:47.879 --> 00:12:50.080
<v Speaker 1>Publisher action would you like a quick action today?

251
00:12:50.159 --> 00:12:52.879
<v Speaker 2>Yeah, basically a quick action. This was placed right on

252
00:12:52.919 --> 00:12:56.120
<v Speaker 2>the course application record page, probably in the chatter feed.

253
00:12:56.519 --> 00:12:59.320
<v Speaker 2>It let a selection officer quickly pop open a little form,

254
00:12:59.480 --> 00:13:02.840
<v Speaker 2>enter their disis, admit, reject, add some notes, update the

255
00:13:02.879 --> 00:13:03.840
<v Speaker 2>status field.

256
00:13:03.679 --> 00:13:06.279
<v Speaker 1>All directly from the context of that record's.

257
00:13:05.879 --> 00:13:09.120
<v Speaker 2>Feed exactly, and it would automatically generate a chatter posting,

258
00:13:09.200 --> 00:13:13.360
<v Speaker 2>decision entered, admit, or whatever super streamline for that common task,

259
00:13:13.399 --> 00:13:15.759
<v Speaker 2>and it kept everyone collaborating on that record informed right

260
00:13:15.759 --> 00:13:16.360
<v Speaker 2>there in the feed.

261
00:13:16.679 --> 00:13:20.799
<v Speaker 1>Nice. So this blueprint it really showcases building these complex

262
00:13:21.240 --> 00:13:24.960
<v Speaker 1>human centric business processes and to end on the platform

263
00:13:25.440 --> 00:13:29.000
<v Speaker 1>using that mix of declarative tools and code where needed.

264
00:13:29.159 --> 00:13:32.440
<v Speaker 2>Definitely, and they mentioned potential next steps too, like adding

265
00:13:32.480 --> 00:13:37.279
<v Speaker 2>an approvals process or workflows to automatically email applicants their results.

266
00:13:37.279 --> 00:13:39.240
<v Speaker 2>You can see how you'd layer more automation on top.

267
00:13:39.480 --> 00:13:43.960
<v Speaker 1>Okay, shifting focus again. Reporting can't run a business or

268
00:13:44.080 --> 00:13:47.679
<v Speaker 1>university without good reporting. The source even quotes that classic

269
00:13:47.759 --> 00:13:50.320
<v Speaker 1>line if you cannot measure it, you cannot improve it.

270
00:13:51.000 --> 00:13:52.039
<v Speaker 2>A fundamental truth.

271
00:13:52.279 --> 00:13:55.159
<v Speaker 1>But this blueprint it's not really about standard salesforce reports

272
00:13:55.159 --> 00:13:59.519
<v Speaker 1>and dashboards, is it. It's about building custom reporting capabilities.

273
00:13:58.759 --> 00:14:02.399
<v Speaker 2>Exactly when the standard out of the box reporting tools

274
00:14:02.440 --> 00:14:06.000
<v Speaker 2>maybe don't give you the specific calculations, the specific layout,

275
00:14:06.080 --> 00:14:07.559
<v Speaker 2>or maybe the performance you need.

276
00:14:07.679 --> 00:14:10.399
<v Speaker 1>And the example they use is an executive information system

277
00:14:10.759 --> 00:14:15.840
<v Speaker 1>an EIS dashboard for a fictional force majure insurance brokers.

278
00:14:16.279 --> 00:14:17.080
<v Speaker 1>Sound serious?

279
00:14:17.399 --> 00:14:21.039
<v Speaker 2>Yeah, The goal was to provide those specific aggregated key

280
00:14:21.080 --> 00:14:25.919
<v Speaker 2>performance indicators KPIs that executives need at a glance, things

281
00:14:25.919 --> 00:14:29.159
<v Speaker 2>that might require complex calculations or pulling data together in

282
00:14:29.240 --> 00:14:31.120
<v Speaker 2>ways standard reports struggle with.

283
00:14:31.600 --> 00:14:35.039
<v Speaker 1>Okay, So how do they approach building that custom reporting

284
00:14:35.080 --> 00:14:37.080
<v Speaker 1>engine on force dot com? Where does it start?

285
00:14:38.080 --> 00:14:40.399
<v Speaker 2>Well, like the others, it starts with the data model

286
00:14:40.440 --> 00:14:43.799
<v Speaker 2>required for the report itself. They outline custom objects like

287
00:14:43.960 --> 00:14:47.120
<v Speaker 2>EIS policy to hold the core insurance policy data, and

288
00:14:47.159 --> 00:14:49.720
<v Speaker 2>another object called EIS dashboard.

289
00:14:49.960 --> 00:14:52.240
<v Speaker 1>An EIS dashboard object, what's that for?

290
00:14:52.840 --> 00:14:55.559
<v Speaker 2>The book suggests that in a real production environment you

291
00:14:55.639 --> 00:14:59.399
<v Speaker 2>might use something like analytical snapshots scheduled jobs that capture

292
00:14:59.399 --> 00:15:03.559
<v Speaker 2>aggregated overtime to populate this EIS dashboard object, so it

293
00:15:03.600 --> 00:15:06.279
<v Speaker 2>holds the historical trend data needed for the dashboard.

294
00:15:06.360 --> 00:15:09.519
<v Speaker 1>Ah okay, a way to snapshot results for performance and

295
00:15:09.559 --> 00:15:10.559
<v Speaker 1>trending exactly.

296
00:15:10.720 --> 00:15:13.360
<v Speaker 2>And then they detail adding the specific fields needed on

297
00:15:13.399 --> 00:15:17.200
<v Speaker 2>the EIS policy object, things like policy date, policy type

298
00:15:17.279 --> 00:15:21.159
<v Speaker 2>like auto home life, policy amount, whether it's a renewal,

299
00:15:21.200 --> 00:15:23.840
<v Speaker 2>the renewal date, all the raw data points the customer

300
00:15:23.840 --> 00:15:24.759
<v Speaker 2>report wanted to crunch.

301
00:15:25.000 --> 00:15:27.679
<v Speaker 1>So you've get the data structure defined. Where does the

302
00:15:27.679 --> 00:15:30.679
<v Speaker 1>custom logic the calculation engine actually live.

303
00:15:31.120 --> 00:15:34.360
<v Speaker 2>That's handled primarily by an APEX controller paired with a

304
00:15:34.480 --> 00:15:37.799
<v Speaker 2>visual force page for the display. The APEX controller is

305
00:15:37.840 --> 00:15:39.240
<v Speaker 2>really the brains of this operation.

306
00:15:39.519 --> 00:15:39.879
<v Speaker 1>Okay.

307
00:15:40.080 --> 00:15:43.679
<v Speaker 2>It defines properties to hold the filtering criteria the user

308
00:15:43.720 --> 00:15:46.320
<v Speaker 2>selects on the page like a start an end date range,

309
00:15:46.559 --> 00:15:50.320
<v Speaker 2>maybe filter by policy type. And importantly it has properties

310
00:15:50.360 --> 00:15:54.039
<v Speaker 2>to store the final calculated KPI values that will be displayed.

311
00:15:54.559 --> 00:15:58.159
<v Speaker 1>And does the controller handle getting the filter options too,

312
00:15:58.720 --> 00:16:00.000
<v Speaker 1>like the lurk of policy type.

313
00:16:00.159 --> 00:16:02.759
<v Speaker 2>Yeah, and there's a neat detail mention. The controllers constructor

314
00:16:02.799 --> 00:16:06.080
<v Speaker 2>can dynamically populate the options for the policy type. PICKLST

315
00:16:06.080 --> 00:16:09.000
<v Speaker 2>filter on the page It does this by introspecting the

316
00:16:09.000 --> 00:16:12.960
<v Speaker 2>schema of the es policic object using apex code schema

317
00:16:13.120 --> 00:16:15.440
<v Speaker 2>dot pickless entry, so if you add a new policy

318
00:16:15.440 --> 00:16:18.080
<v Speaker 2>type later, it automatically shows up as a filter option.

319
00:16:18.200 --> 00:16:21.480
<v Speaker 1>Oh that's nice. Dynamic picklists based on schema are always

320
00:16:21.519 --> 00:16:25.559
<v Speaker 1>good for maintainability avoids hard coding. So what kind of

321
00:16:25.600 --> 00:16:29.200
<v Speaker 1>logic is running inside that controller? To actually calculate the KPIs.

322
00:16:29.480 --> 00:16:33.360
<v Speaker 2>The core methods execute aggregate socle queries. This is where

323
00:16:33.399 --> 00:16:35.919
<v Speaker 2>you leverage the power of the Force dot com database

324
00:16:36.000 --> 00:16:37.919
<v Speaker 2>engine directly from apex.

325
00:16:37.799 --> 00:16:43.200
<v Speaker 1>So using sum count, group by backay exactly.

326
00:16:43.200 --> 00:16:46.440
<v Speaker 2>They use socle functions like some policy amount or counted

327
00:16:46.840 --> 00:16:50.840
<v Speaker 2>to aggregate data from that EIS policy object. They apply

328
00:16:50.960 --> 00:16:53.799
<v Speaker 2>filters based on the user's selected date range and policy

329
00:16:53.840 --> 00:16:57.519
<v Speaker 2>type using wear clauses. Sometimes they group by policy type

330
00:16:57.639 --> 00:16:59.080
<v Speaker 2>or date periods.

331
00:16:58.759 --> 00:17:02.080
<v Speaker 1>And the apex code then takes those raw aggregated results.

332
00:17:01.720 --> 00:17:05.000
<v Speaker 2>From SOCO and performs the final calculations to derive the

333
00:17:05.000 --> 00:17:08.359
<v Speaker 2>specific KPIs. The business needs things like you know, total

334
00:17:08.400 --> 00:17:12.119
<v Speaker 2>renewals amount, renewal success rate percentage, which might involve comparing

335
00:17:12.160 --> 00:17:15.839
<v Speaker 2>counts number of new policies. One maybe policy growth percentage

336
00:17:15.839 --> 00:17:17.200
<v Speaker 2>compared to a previous period.

337
00:17:17.279 --> 00:17:19.680
<v Speaker 1>Got it. So SOCLE does the heavy lifting on aggregation,

338
00:17:19.799 --> 00:17:22.640
<v Speaker 1>APIX does the final math in business logic, and the

339
00:17:22.720 --> 00:17:25.200
<v Speaker 1>Visual Force page is the presentation layer showing this all

340
00:17:25.200 --> 00:17:26.160
<v Speaker 1>to the executive YEP.

341
00:17:26.319 --> 00:17:30.160
<v Speaker 2>The Visual Force page eis dashboard page dot page provides

342
00:17:30.200 --> 00:17:33.400
<v Speaker 2>the user interface. It's got the input fields for selecting

343
00:17:33.440 --> 00:17:36.680
<v Speaker 2>the date, range and policy type filter, a command button

344
00:17:36.680 --> 00:17:40.039
<v Speaker 2>that tells the APEX controller to run the calculations.

345
00:17:39.400 --> 00:17:40.799
<v Speaker 1>And then displays the results.

346
00:17:40.960 --> 00:17:44.559
<v Speaker 2>Right. It displays those calculated KPI values using components like

347
00:17:44.599 --> 00:17:48.880
<v Speaker 2>apex dot output text, and they mention using formatting masks

348
00:17:48.960 --> 00:17:52.880
<v Speaker 2>within the Visual Force to display currency or percentages correctly

349
00:17:52.920 --> 00:17:55.400
<v Speaker 2>like hashtag date zero zero zero zero.

350
00:17:55.240 --> 00:17:56.519
<v Speaker 1>Makes sense for a clean look.

351
00:17:56.640 --> 00:18:00.000
<v Speaker 2>And the blueprint also mentions including visual Force chart components

352
00:18:00.319 --> 00:18:03.400
<v Speaker 2>APAX dot chart to actually visualize some of this data,

353
00:18:03.519 --> 00:18:04.599
<v Speaker 2>not just show numbers.

354
00:18:04.640 --> 00:18:06.880
<v Speaker 1>And they point out a couple of technical details using

355
00:18:06.880 --> 00:18:09.279
<v Speaker 1>read only true on the Visual Force page and setting

356
00:18:09.359 --> 00:18:12.240
<v Speaker 1>doc type HTML five point zero. Why call those out?

357
00:18:12.480 --> 00:18:15.400
<v Speaker 2>Well, read only true was and still is a significant

358
00:18:15.400 --> 00:18:18.319
<v Speaker 2>performance optimization for visual force pages that don't need to

359
00:18:18.359 --> 00:18:21.880
<v Speaker 2>maintain component view state between server requests. If your page

360
00:18:21.960 --> 00:18:25.240
<v Speaker 2>is just displaying data calculated by the controller. Using read

361
00:18:25.279 --> 00:18:27.920
<v Speaker 2>only true can make it load noticeably faster because the

362
00:18:27.920 --> 00:18:31.039
<v Speaker 2>server doesn't have to serialize and de serialize that view state.

363
00:18:31.279 --> 00:18:33.839
<v Speaker 1>Okay, good performance tip, and the doc type.

364
00:18:33.559 --> 00:18:36.319
<v Speaker 2>Setting doc type HTML five point zero just ensures the

365
00:18:36.359 --> 00:18:40.000
<v Speaker 2>page renders using modern HTML five standards, which was becoming

366
00:18:40.039 --> 00:18:43.799
<v Speaker 2>the standard around twenty fourteen. Helps with browser compatibility and

367
00:18:43.920 --> 00:18:46.200
<v Speaker 2>using newer HTML features if needed.

368
00:18:46.480 --> 00:18:48.680
<v Speaker 1>So this blueprint is a great example of how when

369
00:18:48.759 --> 00:18:51.839
<v Speaker 1>standard reports hit their limits, developers could roll up their

370
00:18:51.880 --> 00:18:55.920
<v Speaker 1>sleeves and use APEX and Visual Force to build highly customized,

371
00:18:55.920 --> 00:19:01.039
<v Speaker 1>potentially complex, data heavy dashboards directly on the platform, leveraging

372
00:19:01.039 --> 00:19:03.119
<v Speaker 1>its database power and programmatic control.

373
00:19:03.319 --> 00:19:07.079
<v Speaker 2>Absolutely, it really highlights that flexibility for bespoke reporting needs.

374
00:19:07.240 --> 00:19:10.400
<v Speaker 1>Okay, now let's talk mobile. The mobile revolution was definitely

375
00:19:10.400 --> 00:19:13.680
<v Speaker 1>in full swing by twenty fourteen. Salesforce one had launched,

376
00:19:14.079 --> 00:19:16.960
<v Speaker 1>so the sources dive into building mobile applications using the

377
00:19:16.960 --> 00:19:18.279
<v Speaker 1>Salesforce Mobile SDK.

378
00:19:18.480 --> 00:19:21.119
<v Speaker 2>Yeah, they had to address mobile, and they start by

379
00:19:21.160 --> 00:19:23.640
<v Speaker 2>outlining the main approaches you could take back then three

380
00:19:23.720 --> 00:19:27.279
<v Speaker 2>main paths. One was building pure HTML five web apps

381
00:19:27.400 --> 00:19:29.759
<v Speaker 2>designed to run well in a mobile browser. Or within

382
00:19:29.799 --> 00:19:33.519
<v Speaker 2>the Salesforce one container. Second was hybrid apps, typically using

383
00:19:33.519 --> 00:19:36.720
<v Speaker 2>a patche cordova, which lets you wrap your web code HTML, CSS,

384
00:19:36.799 --> 00:19:39.839
<v Speaker 2>JavaScript inside a native app shell, giving you access to

385
00:19:39.880 --> 00:19:41.240
<v Speaker 2>some device features.

386
00:19:40.880 --> 00:19:42.880
<v Speaker 1>Right like a web app pretending to be a native app.

387
00:19:43.000 --> 00:19:46.000
<v Speaker 2>Kind of yeah. And the third path was fully native

388
00:19:46.039 --> 00:19:50.680
<v Speaker 2>apps using the specific Salesforce mobile SDKs for iOS and

389
00:19:50.680 --> 00:19:54.400
<v Speaker 2>Android to build apps using objective C, Swift or Java.

390
00:19:54.519 --> 00:19:56.519
<v Speaker 1>In which path does this blueprint focus on?

391
00:19:56.880 --> 00:20:00.519
<v Speaker 2>This specific blueprint digs primarily into the HTML five approach,

392
00:20:00.759 --> 00:20:03.519
<v Speaker 2>which was pretty popular because it let web developers leverage

393
00:20:03.559 --> 00:20:08.279
<v Speaker 2>their existing skills HTML, JavaScript's CSS to build mobile experiences

394
00:20:08.319 --> 00:20:10.319
<v Speaker 2>connected to Salesforce relatively quickly.

395
00:20:10.720 --> 00:20:14.240
<v Speaker 1>So htail five mobile apps. What kind of web technologies

396
00:20:14.240 --> 00:20:16.240
<v Speaker 1>are they combining here? In this blueprint?

397
00:20:16.359 --> 00:20:18.640
<v Speaker 2>The core idea was building these things called single page

398
00:20:18.680 --> 00:20:22.039
<v Speaker 2>applications or spas, where most of the UI and logic

399
00:20:22.119 --> 00:20:26.039
<v Speaker 2>runs in the browser using JavaScript. The blueprint specifically mentions

400
00:20:26.319 --> 00:20:29.920
<v Speaker 2>using Angular JS, which was a really popular JavaScript framework

401
00:20:30.160 --> 00:20:33.759
<v Speaker 2>back then maintained by Google well suited for this kind

402
00:20:33.759 --> 00:20:37.200
<v Speaker 2>of model view controller NBC architecture in the front end.

403
00:20:37.279 --> 00:20:39.119
<v Speaker 1>Okay, angular JS? What else?

404
00:20:39.319 --> 00:20:42.440
<v Speaker 2>They also leverage Twitter Bootstrap for the UI components and

405
00:20:42.480 --> 00:20:45.079
<v Speaker 2>making the layout responsive so it looked okay on phones

406
00:20:45.079 --> 00:20:47.640
<v Speaker 2>and tablets without writing tons of custom CSS.

407
00:20:47.759 --> 00:20:50.079
<v Speaker 1>Bootstraps still around very useful.

408
00:20:49.920 --> 00:20:52.759
<v Speaker 2>And jQuery, which was pretty much ubiquitous back then and

409
00:20:52.799 --> 00:20:55.960
<v Speaker 2>also a dependency for some of the Salesforce Mobile SDK's

410
00:20:56.039 --> 00:20:57.200
<v Speaker 2>JavaScript libraries.

411
00:20:57.400 --> 00:21:01.720
<v Speaker 1>So you've got Angular Bootstrap, jQuery running as an HTML

412
00:21:01.839 --> 00:21:05.039
<v Speaker 1>five app. How does it actually connect to Salesforce data

413
00:21:05.039 --> 00:21:06.119
<v Speaker 1>and handle authentication?

414
00:21:06.640 --> 00:21:10.039
<v Speaker 2>That's where the Salesforce Mobile SDK libraries come in. The

415
00:21:10.039 --> 00:21:13.559
<v Speaker 2>blueprint details setting up the application files, including downloading a

416
00:21:13.599 --> 00:21:17.880
<v Speaker 2>specific Salesforce Angular JS mobile pack they provided back then, okay.

417
00:21:17.640 --> 00:21:19.440
<v Speaker 1>A specific pack for Angular integration.

418
00:21:19.880 --> 00:21:23.839
<v Speaker 2>Yeah, and key parts involved initializing the Angular JS app

419
00:21:23.880 --> 00:21:27.319
<v Speaker 2>correctly and wiring it up with the SDK's JavaScript libraries,

420
00:21:27.559 --> 00:21:32.119
<v Speaker 2>things like Angularforce, dot JS, Force Attk dot Mobile SDKJS.

421
00:21:32.799 --> 00:21:34.559
<v Speaker 2>These libraries handled.

422
00:21:34.200 --> 00:21:36.480
<v Speaker 1>The hard parts looked like authentication exactly.

423
00:21:36.640 --> 00:21:40.359
<v Speaker 2>The blueprint explains the authentication flow, which relied on Angular

424
00:21:40.400 --> 00:21:44.720
<v Speaker 2>JS controllers managing the Salesforce OS process, you know, initiating

425
00:21:44.759 --> 00:21:47.359
<v Speaker 2>the log in, handling the callback from Salesforce with the

426
00:21:47.400 --> 00:21:51.799
<v Speaker 2>access token, storing token securely, refreshing them when needed and

427
00:21:51.920 --> 00:21:55.400
<v Speaker 2>redirecting users once they were logged in. The SDK libraries

428
00:21:55.440 --> 00:21:57.039
<v Speaker 2>provided functions to help with all that.

429
00:21:57.319 --> 00:22:00.240
<v Speaker 1>Okay, so the users authenticated, the framework is set up up,

430
00:22:00.839 --> 00:22:03.279
<v Speaker 1>how do you actually get the business data, like say,

431
00:22:03.559 --> 00:22:06.200
<v Speaker 1>catching opportunity records to display in the mobile app.

432
00:22:06.279 --> 00:22:08.400
<v Speaker 2>This is where they show a common pattern from the

433
00:22:08.440 --> 00:22:13.000
<v Speaker 2>Angular JS world, creating something called an opportunity factory a factory.

434
00:22:13.279 --> 00:22:16.680
<v Speaker 2>In Angular terms, a factory was basically a reusable service,

435
00:22:16.759 --> 00:22:19.119
<v Speaker 2>a chunk of code designed to interact with the Salesforce

436
00:22:19.200 --> 00:22:22.720
<v Speaker 2>data via the SDK's helper functions. So this opportunity factory

437
00:22:22.720 --> 00:22:27.039
<v Speaker 2>would have methods like get less opportunities, get opportunity details, opportunity.

438
00:22:26.599 --> 00:22:29.039
<v Speaker 1>At standard CRD like operations.

439
00:22:29.160 --> 00:22:32.160
<v Speaker 2>Pretty much, but here's where it gets especially interesting. The

440
00:22:32.240 --> 00:22:36.240
<v Speaker 2>factory also had a method like get opportunities nearby latitude,

441
00:22:36.319 --> 00:22:37.160
<v Speaker 2>longitude radius.

442
00:22:37.240 --> 00:22:40.000
<v Speaker 1>Wait, hang on, the mobile app can query Salesforce for

443
00:22:40.039 --> 00:22:43.079
<v Speaker 1>records based on geographic location. How does that work? That

444
00:22:43.160 --> 00:22:44.920
<v Speaker 1>sounds pretty advanced for twenty fourteen.

445
00:22:45.160 --> 00:22:48.359
<v Speaker 2>It was pretty cool. It leveraged a specific soacole query

446
00:22:48.400 --> 00:22:53.279
<v Speaker 2>capability called geolocation and distance, but it required some significant

447
00:22:53.279 --> 00:22:55.599
<v Speaker 2>setup on the back end and Salesforce.

448
00:22:55.119 --> 00:22:56.559
<v Speaker 1>First, okay, what kind of setup.

449
00:22:56.759 --> 00:23:00.000
<v Speaker 2>Well, first, to even store location data, the blue print

450
00:23:00.200 --> 00:23:03.680
<v Speaker 2>shows adding a new field to the account object in salesforce,

451
00:23:04.160 --> 00:23:07.599
<v Speaker 2>a field of the geolocation data type, which stores latitude

452
00:23:07.599 --> 00:23:08.799
<v Speaker 2>and longitude coordinates.

453
00:23:08.880 --> 00:23:10.880
<v Speaker 1>Right, you need somewhere to put the coordinates. Yeah, but

454
00:23:11.039 --> 00:23:14.160
<v Speaker 1>how do those coordinates get into that field? Accounts usually

455
00:23:14.200 --> 00:23:15.640
<v Speaker 1>just have billing addresses.

456
00:23:15.920 --> 00:23:19.319
<v Speaker 2>Ah, good question. They don't magically appear. This required more work.

457
00:23:19.359 --> 00:23:23.480
<v Speaker 2>It required code APEX again. Yep, the blueprint includes an

458
00:23:23.480 --> 00:23:27.960
<v Speaker 2>APEX utility class and crucially, an APEX trigger. This trigger

459
00:23:28.000 --> 00:23:31.000
<v Speaker 2>fired whenever an account record was inserted or updated.

460
00:23:31.079 --> 00:23:32.000
<v Speaker 1>And what does the trigger do?

461
00:23:32.319 --> 00:23:36.039
<v Speaker 2>It automatically made an HTTP call out from APEX to

462
00:23:36.079 --> 00:23:40.680
<v Speaker 2>an external service, specifically the Google geocoding API. It sent

463
00:23:40.759 --> 00:23:45.079
<v Speaker 2>the account's billing address, street, city, state ZIP to Google.

464
00:23:45.079 --> 00:23:47.839
<v Speaker 1>And Google's API sent back the latitude and longitude for

465
00:23:47.839 --> 00:23:48.880
<v Speaker 1>that address exactly.

466
00:23:49.279 --> 00:23:52.960
<v Speaker 2>The APEX trigger then took those coordinates returned by Google

467
00:23:53.319 --> 00:23:56.279
<v Speaker 2>and saved them into that new geolocation field on the

468
00:23:56.319 --> 00:23:57.119
<v Speaker 2>account record.

469
00:23:57.319 --> 00:24:00.240
<v Speaker 1>Wow. Okay, hold on, so they're using an APEX You're

470
00:24:00.279 --> 00:24:02.880
<v Speaker 1>firing on save to make a real time web service

471
00:24:02.920 --> 00:24:06.440
<v Speaker 1>call out to an external api. Google just to enrich

472
00:24:06.480 --> 00:24:09.400
<v Speaker 1>the Salesforce data with coordinates before the mobile app even

473
00:24:09.400 --> 00:24:12.039
<v Speaker 1>tries to query base on location. That's quite a bit

474
00:24:12.039 --> 00:24:14.720
<v Speaker 1>of back end automation just to enable that one mobile feature.

475
00:24:14.799 --> 00:24:17.359
<v Speaker 2>It absolutely is, and it wasn't trivial to set up.

476
00:24:17.359 --> 00:24:20.440
<v Speaker 2>It required configuring a remote site setting in Salesforce to

477
00:24:20.480 --> 00:24:24.200
<v Speaker 2>allow APEX to make calouts to the Google Api endpoint.

478
00:24:24.400 --> 00:24:26.440
<v Speaker 2>And you need to get a Google API key which

479
00:24:26.519 --> 00:24:27.839
<v Speaker 2>might have had usage limits or.

480
00:24:27.759 --> 00:24:31.519
<v Speaker 1>Costs, right external dependencies. So, once all that back end

481
00:24:31.519 --> 00:24:33.920
<v Speaker 1>work is done, the geofield exists, the trigger is firing,

482
00:24:34.119 --> 00:24:36.759
<v Speaker 1>accounts are getting geocoded, and how does the mobile app

483
00:24:36.880 --> 00:24:37.119
<v Speaker 1>use it?

484
00:24:37.440 --> 00:24:40.960
<v Speaker 2>Okay, So now the mobile app, using an Angular JS

485
00:24:41.000 --> 00:24:44.200
<v Speaker 2>controller to call it. An opmap controller in the example

486
00:24:44.519 --> 00:24:48.880
<v Speaker 2>could first get the user's current location from the device's GPS.

487
00:24:48.599 --> 00:24:53.440
<v Speaker 1>Using browser geolocation APIs or Cordova plugins probably yeah.

488
00:24:53.640 --> 00:24:57.200
<v Speaker 2>Then, armed with the user's current lat long, that controller

489
00:24:57.240 --> 00:24:59.960
<v Speaker 2>could call the get opportunities nearby method in the op

490
00:25:00.000 --> 00:25:01.279
<v Speaker 2>Portunity factory.

491
00:25:01.119 --> 00:25:03.960
<v Speaker 1>And that factory method would use the Salesforce Mobile.

492
00:25:03.759 --> 00:25:08.240
<v Speaker 2>SDK to construct a specific soacle query using the distance function,

493
00:25:08.640 --> 00:25:12.559
<v Speaker 2>something like select name from opportunity where distance account location

494
00:25:12.680 --> 00:25:17.480
<v Speaker 2>lacktuon uger lab user lawn my five searching for opportunities

495
00:25:17.480 --> 00:25:21.160
<v Speaker 2>linked to accounts whose location field is within say five

496
00:25:21.240 --> 00:25:22.680
<v Speaker 2>miles of the user's current.

497
00:25:22.480 --> 00:25:25.319
<v Speaker 1>Location, and Salesforce handles that spatial query on the back

498
00:25:25.400 --> 00:25:27.240
<v Speaker 1>end using the index geolocation field.

499
00:25:27.759 --> 00:25:29.599
<v Speaker 2>Then the results come back to the mobile app, and

500
00:25:29.640 --> 00:25:32.200
<v Speaker 2>the outmap controller could take that list of nearby opportunities

501
00:25:32.200 --> 00:25:34.839
<v Speaker 2>and display them as markers on an embedded Google Map

502
00:25:34.920 --> 00:25:36.519
<v Speaker 2>within the HTML five app.

503
00:25:36.680 --> 00:25:39.640
<v Speaker 1>That is, that's a really impressive end to end scenario.

504
00:25:40.000 --> 00:25:44.000
<v Speaker 1>It perfectly demonstrates building a truly context a wear location

505
00:25:44.160 --> 00:25:48.480
<v Speaker 1>based mobile experience, but it involves combining front end web tech,

506
00:25:48.759 --> 00:25:53.000
<v Speaker 1>Angular bootstrap maps, the mobile SDK for data access, and

507
00:25:53.119 --> 00:25:57.319
<v Speaker 1>off significant back end APEX automation for data enrichment and

508
00:25:57.400 --> 00:26:00.759
<v Speaker 1>integration with external APIs like Google goocode shows all the

509
00:26:00.799 --> 00:26:01.599
<v Speaker 1>layers you might need.

510
00:26:01.880 --> 00:26:03.920
<v Speaker 2>It really does. It brings home that idea of Force

511
00:26:03.960 --> 00:26:06.599
<v Speaker 2>dot com as a platform you build on leveraging all

512
00:26:06.640 --> 00:26:09.680
<v Speaker 2>its pieces, not just in the standard UI, and the

513
00:26:09.680 --> 00:26:12.880
<v Speaker 2>blueprint also briefly touches on setting up the native Android

514
00:26:12.920 --> 00:26:16.720
<v Speaker 2>SDK using the forstraid command, hinting at that alternative path too.

515
00:26:17.119 --> 00:26:20.319
<v Speaker 1>Fascinating stuff. Okay, one final blueprint. This one takes the

516
00:26:20.359 --> 00:26:23.279
<v Speaker 1>idea of external integration even further. It's about connecting a

517
00:26:23.319 --> 00:26:27.640
<v Speaker 1>Force dot Com application to another major cloud platform, specifically

518
00:26:27.880 --> 00:26:29.279
<v Speaker 1>Microsoft Windows Azure.

519
00:26:29.519 --> 00:26:32.920
<v Speaker 2>Yeah, this one pushes the integration boundary, and the particular

520
00:26:32.920 --> 00:26:35.680
<v Speaker 2>Azure service they explore is Azure Notification Hubs.

521
00:26:35.880 --> 00:26:38.880
<v Speaker 1>Notification HUBS so for sending push notifications to mobile.

522
00:26:38.640 --> 00:26:43.599
<v Speaker 2>Apps, exactly as your Notification Hubs was and is Microsoft

523
00:26:43.640 --> 00:26:47.559
<v Speaker 2>service designed to simplify sending mobile push notifications reliably across

524
00:26:47.599 --> 00:26:54.440
<v Speaker 2>all the different platforms iOS, APNS, Android, GCMFCM, Windows devices,

525
00:26:54.559 --> 00:26:57.119
<v Speaker 2>all through a single unified rest API.

526
00:26:57.480 --> 00:27:00.880
<v Speaker 1>As it abstracts away the complexity of talking directly to

527
00:27:01.519 --> 00:27:03.480
<v Speaker 1>apples and Google's push.

528
00:27:03.200 --> 00:27:07.279
<v Speaker 2>Services precisely that was the big value prop handles, load balancing, queuing,

529
00:27:07.599 --> 00:27:10.400
<v Speaker 2>device registration management, all that complexity for you.

530
00:27:10.519 --> 00:27:13.359
<v Speaker 1>So this blueprint is about using Force dot Com to

531
00:27:13.440 --> 00:27:16.799
<v Speaker 1>initiate sending push notifications out to mobile apps, potentially apps

532
00:27:16.799 --> 00:27:20.240
<v Speaker 1>built using the Salesforce Native SDK, but leveraging Azure as

533
00:27:20.279 --> 00:27:21.319
<v Speaker 1>the delivery mechanism.

534
00:27:21.440 --> 00:27:24.160
<v Speaker 2>You got it. And this blueprint actually assumes you're working

535
00:27:24.160 --> 00:27:27.160
<v Speaker 2>with a native Android application, one built using the Salesforce

536
00:27:27.200 --> 00:27:30.880
<v Speaker 2>Android Native Mobile SDK, unlike the previous Ashmel five example.

537
00:27:30.960 --> 00:27:32.799
<v Speaker 1>Okay, so native Android this time. Yeah.

538
00:27:32.920 --> 00:27:36.920
<v Speaker 2>The setup section details getting the Android Developer Tools ADT bundle,

539
00:27:37.240 --> 00:27:40.920
<v Speaker 2>setting up an Android Virtual Device add for testing, and

540
00:27:41.000 --> 00:27:44.640
<v Speaker 2>installing the Salesforce Android Native Mobile SDK using that four

541
00:27:44.680 --> 00:27:47.759
<v Speaker 2>stroid command line tool we mentioned, and of course configuring

542
00:27:47.839 --> 00:27:51.200
<v Speaker 2>the Salesforce Connected app with the right otooth settings for

543
00:27:51.240 --> 00:27:52.200
<v Speaker 2>a native mobile app.

544
00:27:52.240 --> 00:27:55.359
<v Speaker 1>Flow makes sense. What about the setup needed on the

545
00:27:55.400 --> 00:27:56.160
<v Speaker 1>Azure side.

546
00:27:56.240 --> 00:27:58.759
<v Speaker 2>On the Azure side, you first need to interact with

547
00:27:58.880 --> 00:28:02.000
<v Speaker 2>Google Cloud Messaging GCM which is now Fire Based Cloud

548
00:28:02.039 --> 00:28:05.160
<v Speaker 2>Messaging FCM, to get an API project number and an

549
00:28:05.160 --> 00:28:08.359
<v Speaker 2>API key. Azure needs these credentials to be allowed to

550
00:28:08.400 --> 00:28:12.240
<v Speaker 2>send notifications via Google's infrastructure to Android devices.

551
00:28:12.240 --> 00:28:13.400
<v Speaker 1>Ok to yeah, the Google keys.

552
00:28:13.599 --> 00:28:16.640
<v Speaker 2>Then you can figure the Azure notification hub itself within

553
00:28:16.680 --> 00:28:19.400
<v Speaker 2>the Azure portal. You create a name space, then create

554
00:28:19.440 --> 00:28:21.839
<v Speaker 2>a hub within that name space, and critically, you link

555
00:28:21.880 --> 00:28:24.680
<v Speaker 2>that hub to your GCMAPI key so Azure knows how

556
00:28:24.680 --> 00:28:27.079
<v Speaker 2>to talk to Google for your app. You also need

557
00:28:27.119 --> 00:28:30.240
<v Speaker 2>to grab your Azure Service Bus credentials, specifically an endpoint

558
00:28:30.559 --> 00:28:31.960
<v Speaker 2>URL and an access key.

559
00:28:32.000 --> 00:28:33.640
<v Speaker 1>All right, So quite a bit of setup on both

560
00:28:33.640 --> 00:28:38.160
<v Speaker 1>Salesforce Android and Azure Google fronts. Now you have the

561
00:28:38.279 --> 00:28:42.079
<v Speaker 1>native Android app potentially ready to receive notifications and Azure

562
00:28:42.119 --> 00:28:46.279
<v Speaker 1>is configure to send them via GCM. Howdes Force dot

563
00:28:46.319 --> 00:28:49.680
<v Speaker 1>Com actually trigger Azure to send a message? That's the

564
00:28:49.680 --> 00:28:50.519
<v Speaker 1>core in creation right.

565
00:28:50.519 --> 00:28:52.680
<v Speaker 2>That is the core, and it happens via apex code

566
00:28:52.799 --> 00:28:55.880
<v Speaker 2>making callouts from Force dot Com directly to the Azure

567
00:28:55.920 --> 00:28:58.039
<v Speaker 2>notification hubs rest API.

568
00:28:58.200 --> 00:29:01.000
<v Speaker 1>Okay, Apex again talking do external RESTSPI exactly.

569
00:29:01.319 --> 00:29:04.240
<v Speaker 2>The blueprint details building a set of apex classes that

570
00:29:04.279 --> 00:29:06.720
<v Speaker 2>effectively act as a rapper or an interface to the

571
00:29:06.759 --> 00:29:10.440
<v Speaker 2>Azure and Notification hubs API. These classes contain key methods

572
00:29:10.480 --> 00:29:13.000
<v Speaker 2>to like what first a method to get an Azure

573
00:29:13.039 --> 00:29:16.839
<v Speaker 2>access token Back in twenty fourteen, Azure notification hubs often

574
00:29:16.960 --> 00:29:20.039
<v Speaker 2>use something called OWR app for authentication, which was a

575
00:29:20.039 --> 00:29:24.559
<v Speaker 2>specific token exchange protocol. It involved making an http PST

576
00:29:24.759 --> 00:29:28.480
<v Speaker 2>request from Apex to a specific Azure ooth wr at endpoint,

577
00:29:28.559 --> 00:29:30.960
<v Speaker 2>sending your Azure credentials like the default issuer and a

578
00:29:30.960 --> 00:29:32.599
<v Speaker 2>default t from your service bus.

579
00:29:32.359 --> 00:29:35.039
<v Speaker 1>Credential, and that calla would need a remote site setting

580
00:29:35.039 --> 00:29:38.000
<v Speaker 1>in Salesforce right to allow Apex to call the Azure.

581
00:29:37.759 --> 00:29:42.240
<v Speaker 2>Endpoint absolutely required a remote site setting. The response gave

582
00:29:42.279 --> 00:29:46.160
<v Speaker 2>you a short lived access token. Second, maybe a method

583
00:29:46.160 --> 00:29:48.640
<v Speaker 2>to query Azure to get a list of existing device

584
00:29:48.720 --> 00:29:52.920
<v Speaker 2>registrations associated with your notification hub. See which mobile users

585
00:29:52.920 --> 00:29:55.319
<v Speaker 2>have actually registered their devices with Azure.

586
00:29:55.400 --> 00:29:57.160
<v Speaker 1>Okay, so you can see who's listening yep.

587
00:29:57.559 --> 00:30:00.880
<v Speaker 2>And third, the most crucial step, the method to actually

588
00:30:00.920 --> 00:30:04.440
<v Speaker 2>send a message through the notification hub. This involved making

589
00:30:04.440 --> 00:30:08.400
<v Speaker 2>another http PST request from Apex, this time to the

590
00:30:08.440 --> 00:30:12.680
<v Speaker 2>notification hub's main rest API endpoint, which needed another remote

591
00:30:12.680 --> 00:30:14.720
<v Speaker 2>site setting for the hub's namespace RL.

592
00:30:14.960 --> 00:30:17.240
<v Speaker 1>And what goes in that post request.

593
00:30:17.039 --> 00:30:20.000
<v Speaker 2>You'd include the Azure access token you obtained earlier. In

594
00:30:20.039 --> 00:30:24.200
<v Speaker 2>the authorization header, you'd specified target tags. Azure notification hubs

595
00:30:24.279 --> 00:30:27.240
<v Speaker 2>uses tags for targeting. A common pattern was to have

596
00:30:27.279 --> 00:30:30.640
<v Speaker 2>the mobile app register itself with Azure using the Salesforce

597
00:30:30.759 --> 00:30:33.880
<v Speaker 2>user idea as a tag. So from Apex you could

598
00:30:33.880 --> 00:30:37.240
<v Speaker 2>target the message to a specific Salesforce user ID tag.

599
00:30:37.519 --> 00:30:39.759
<v Speaker 2>And of course you include the actual message payload you

600
00:30:39.799 --> 00:30:41.200
<v Speaker 2>want to send in the request body.

601
00:30:41.440 --> 00:30:45.480
<v Speaker 1>Wow. Okay, so Apex is potentially making one cal out

602
00:30:45.519 --> 00:30:48.759
<v Speaker 1>to get an Azure token. Maybe another to query registrations,

603
00:30:48.759 --> 00:30:51.039
<v Speaker 1>and then a third cal out to actually send the

604
00:30:51.039 --> 00:30:55.960
<v Speaker 1>notification payload to a specific tag via the Azure rest API.

605
00:30:56.440 --> 00:30:59.400
<v Speaker 1>This sounds pretty intricate, a multi step cloud to cloud integration.

606
00:30:59.559 --> 00:31:02.759
<v Speaker 2>It is definitely intricate, but it highlights the platform's capability

607
00:31:02.799 --> 00:31:06.319
<v Speaker 2>back then to perform these complex server to server integrations

608
00:31:06.599 --> 00:31:10.200
<v Speaker 2>directly interacting with other major cloud providers. APIs right from

609
00:31:10.240 --> 00:31:11.519
<v Speaker 2>within apex code.

610
00:31:11.599 --> 00:31:14.599
<v Speaker 1>Okay, so Apex handles the back end communication with Asher.

611
00:31:15.359 --> 00:31:18.119
<v Speaker 1>How does a regular Salesforce user initiate this? They don't

612
00:31:18.160 --> 00:31:19.319
<v Speaker 1>write apex right.

613
00:31:19.400 --> 00:31:21.559
<v Speaker 2>So the final piece of the blueprint is building a

614
00:31:21.640 --> 00:31:25.640
<v Speaker 2>simple user interface within Force dot com a visual Force

615
00:31:25.680 --> 00:31:27.160
<v Speaker 2>page and a supporting.

616
00:31:26.759 --> 00:31:28.759
<v Speaker 1>Apex controller, and what does his page let them do?

617
00:31:29.240 --> 00:31:32.440
<v Speaker 2>This UI would allow a Salesforce user, maybe a support

618
00:31:32.440 --> 00:31:36.000
<v Speaker 2>agent or a manager, to say, select which registered mobile

619
00:31:36.039 --> 00:31:38.440
<v Speaker 2>user they want to send a message to. The picklist

620
00:31:38.440 --> 00:31:42.000
<v Speaker 2>of users could be populated by querying Salesforce user records

621
00:31:42.000 --> 00:31:45.359
<v Speaker 2>whose user IDs match the registration tags retrieved from Azure.

622
00:31:45.640 --> 00:31:48.279
<v Speaker 2>Using that second Apex method we talked about clever, so

623
00:31:48.319 --> 00:31:51.880
<v Speaker 2>you only show users who actually have the app registered exactly.

624
00:31:51.680 --> 00:31:53.559
<v Speaker 1>And then there'd be a text box to type the

625
00:31:53.599 --> 00:31:56.960
<v Speaker 1>message content. When the Salesforce user clicks a send message

626
00:31:57.000 --> 00:31:59.079
<v Speaker 1>button on the visual Force page.

627
00:31:58.720 --> 00:32:01.599
<v Speaker 2>The controller calls that third APEX method, which makes the

628
00:32:01.680 --> 00:32:04.960
<v Speaker 2>call out to the Adjure Notification Hub rest API, passing

629
00:32:04.960 --> 00:32:08.119
<v Speaker 2>the selected user ID tag and the message text precisely.

630
00:32:08.400 --> 00:32:11.839
<v Speaker 1>Azure then takes over, finds the device registered with that

631
00:32:11.920 --> 00:32:16.920
<v Speaker 1>tag and sends the push notification via Google's GCMFCM infrastructure

632
00:32:17.160 --> 00:32:18.720
<v Speaker 1>to the user's Android device.

633
00:32:18.880 --> 00:32:22.279
<v Speaker 2>That's a very sophisticated blueprint. It really demonstrates a complex

634
00:32:22.319 --> 00:32:25.720
<v Speaker 2>cloud to cloud integration pattern. Plus the cloud to mobile piece,

635
00:32:26.039 --> 00:32:29.799
<v Speaker 2>all orchestrated and initiated from within Force dot Com shows

636
00:32:29.799 --> 00:32:32.279
<v Speaker 2>its potential as a central command center for these kinds

637
00:32:32.319 --> 00:32:33.480
<v Speaker 2>of connected applications.

638
00:32:33.680 --> 00:32:36.480
<v Speaker 1>Absolutely, it ties a lot of different pieces together, native

639
00:32:36.480 --> 00:32:41.119
<v Speaker 1>mobile SDK, apex colouts, external cloud services, visual Force UI.

640
00:32:41.440 --> 00:32:43.680
<v Speaker 1>So let's try and wrap this deep dive up. We've

641
00:32:43.720 --> 00:32:47.839
<v Speaker 1>looked at these six predistinct blueprints from this twenty fourteen

642
00:32:47.880 --> 00:32:52.920
<v Speaker 1>book building communities, e commerce, back ends, internal CRM processes,

643
00:32:52.960 --> 00:32:57.839
<v Speaker 1>custom reporting, mobile apps, cloud integrations. What's the big picture

644
00:32:57.920 --> 00:32:59.759
<v Speaker 1>takeaway when you look back at all of them.

645
00:33:00.240 --> 00:33:03.160
<v Speaker 2>Well, the clear picture that emerges, I think is that

646
00:33:03.319 --> 00:33:06.519
<v Speaker 2>Force dot Com even a decade ago, was being presented

647
00:33:06.559 --> 00:33:10.680
<v Speaker 2>and used as a really highly capable, very adaptable platform.

648
00:33:10.720 --> 00:33:14.359
<v Speaker 2>It wasn't just for building standard CRM screens. It could

649
00:33:14.400 --> 00:33:15.000
<v Speaker 2>do much more.

650
00:33:15.079 --> 00:33:17.920
<v Speaker 1>Yeah, you see it being used for external engagement with

651
00:33:18.000 --> 00:33:21.240
<v Speaker 1>those communities and site dot com tools acting. Is that

652
00:33:21.400 --> 00:33:24.799
<v Speaker 1>robust back end, data store and API layer for totally

653
00:33:24.880 --> 00:33:28.319
<v Speaker 1>external systems like that e commerce site running on heroco.

654
00:33:28.079 --> 00:33:30.079
<v Speaker 2>Right, the headless pattern almost.

655
00:33:29.880 --> 00:33:33.359
<v Speaker 1>Powering complex internal business processes with automation like the student

656
00:33:33.400 --> 00:33:37.119
<v Speaker 1>admissions example. Yet workflow in logic, delivering custom beta heavy

657
00:33:37.240 --> 00:33:39.599
<v Speaker 1>reporting dashboards when the standard ones weren't.

658
00:33:39.440 --> 00:33:41.480
<v Speaker 2>Enough, going beyond standard reports.

659
00:33:41.200 --> 00:33:46.160
<v Speaker 1>Building quite sophisticated mobile experiences using the SDK, including location.

660
00:33:45.799 --> 00:33:50.519
<v Speaker 2>Awareness, leveraging device capabilities, and even acting as the orchestrator

661
00:33:50.680 --> 00:33:54.240
<v Speaker 2>for integrations with other major cloud services like as your

662
00:33:54.279 --> 00:33:58.599
<v Speaker 2>notification humps. Yeah, connecting the clouds across all these different scenarios.

663
00:33:58.680 --> 00:34:01.759
<v Speaker 2>You see the same or platform elements being used in

664
00:34:01.759 --> 00:34:02.480
<v Speaker 2>different ways.

665
00:34:02.759 --> 00:34:06.240
<v Speaker 1>You really do you see custom objects providing that flexible

666
00:34:06.319 --> 00:34:10.880
<v Speaker 1>data layer underneath everything. Yeah, you see profiles, permissions rolls

667
00:34:10.920 --> 00:34:14.199
<v Speaker 1>handling the security aspect. You see APEX and visual force

668
00:34:14.199 --> 00:34:17.719
<v Speaker 1>popping up for custom logic, custom UI and especially for

669
00:34:17.760 --> 00:34:21.079
<v Speaker 1>those crucial integrations, and maybe most importantly, you see the

670
00:34:21.119 --> 00:34:24.920
<v Speaker 1>APIs and the SDKs acting as the doorways, the way

671
00:34:25.000 --> 00:34:28.360
<v Speaker 1>to connect Force dot Com outwards to other systems or

672
00:34:28.440 --> 00:34:31.199
<v Speaker 1>to build entirely new experiences like mobile apps on top

673
00:34:31.239 --> 00:34:31.440
<v Speaker 1>of it.

674
00:34:31.719 --> 00:34:34.920
<v Speaker 2>Exactly the platform's strength, even back then, seems to be

675
00:34:35.000 --> 00:34:39.400
<v Speaker 2>rooted in that rapid application development capability, handling the infrastructure

676
00:34:39.440 --> 00:34:41.960
<v Speaker 2>burden for you, while still providing those essential hooks, those

677
00:34:41.960 --> 00:34:45.000
<v Speaker 2>integration points you needed to extend it and connect it

678
00:34:45.000 --> 00:34:45.840
<v Speaker 2>to the wider world.

679
00:34:46.000 --> 00:34:49.559
<v Speaker 1>It's really fascinating to see how these patterns, these blueprints

680
00:34:49.599 --> 00:34:54.239
<v Speaker 1>for integration, for process automation, for leveraging mobile, for connecting clouds,

681
00:34:54.880 --> 00:34:58.679
<v Speaker 1>how they're being defined and implemented using the specific tools

682
00:34:58.679 --> 00:35:01.480
<v Speaker 1>and features available on the PLATF in twenty fourteen.

683
00:35:01.760 --> 00:35:03.760
<v Speaker 2>It really is you can see the foundation being laid

684
00:35:03.880 --> 00:35:06.119
<v Speaker 2>for a lot of what we still do today, just

685
00:35:06.159 --> 00:35:08.280
<v Speaker 2>maybe with different tools sometimes.

686
00:35:08.480 --> 00:35:10.719
<v Speaker 1>Which I guess raises a really interesting question for you

687
00:35:10.840 --> 00:35:14.559
<v Speaker 1>the listener to consider now, given how the technology landscape

688
00:35:14.559 --> 00:35:18.280
<v Speaker 1>and obviously the Salesforce platform itself have evolved since twenty fourteen.

689
00:35:18.639 --> 00:35:21.119
<v Speaker 1>I mean, think about lightning experience, the rise of Flow

690
00:35:21.119 --> 00:35:25.320
<v Speaker 1>for automation, Heroku Connect for data sinc. Newer mobile SDKs,

691
00:35:25.679 --> 00:35:29.280
<v Speaker 1>Lightning web components, way more declarative options for integration.

692
00:35:29.320 --> 00:35:31.920
<v Speaker 2>Now, Yeah, the platform looks quite different in many ways.

693
00:35:32.159 --> 00:35:34.880
<v Speaker 1>So the question is looking back at these twenty fourteen blueprints,

694
00:35:35.440 --> 00:35:38.480
<v Speaker 1>what fundamental ideas, what core patterns do you think remain

695
00:35:38.639 --> 00:35:42.079
<v Speaker 1>absolutely essential for modern salesforce development? And which ones have

696
00:35:42.199 --> 00:35:45.719
<v Speaker 1>maybe been completely abstracted away or of radically changed shape

697
00:35:45.719 --> 00:35:47.159
<v Speaker 1>because of new platform features.

698
00:35:47.320 --> 00:35:50.159
<v Speaker 2>That's a great question. What problems were developer solving back

699
00:35:50.159 --> 00:35:55.519
<v Speaker 2>then with intricate APEX triggers, visual force pages, complex callouts

700
00:35:55.960 --> 00:35:58.880
<v Speaker 2>that maybe you'd solve entirely differently, perhaps much more easily,

701
00:35:59.320 --> 00:36:02.039
<v Speaker 2>using today's two tools like Flow or platform events or

702
00:36:02.079 --> 00:36:04.000
<v Speaker 2>meal soft or different integration patterns.

703
00:36:04.079 --> 00:36:07.000
<v Speaker 1>Yeah, where have the tools evolved to solve those same

704
00:36:07.159 --> 00:36:10.320
<v Speaker 1>underlying business problems in a new way? Something definitely worth

705
00:36:10.320 --> 00:36:10.880
<v Speaker 1>thinking about.