Speaker 1: Okay, let's unpack this one. Yeah, today we're diving into
Speaker 1: something pretty interesting. It's excerpts from a book Force dot
Speaker 1: Com Development Blueprints from back in twenty fourteen.
Speaker 2: Right, twenty fourteen, so like a decade ago now roughly exactly.
Speaker 1: It's kind of like hitting the way of back machine,
Speaker 1: you know, seeing how experienced developers were building some pretty
Speaker 1: sophisticated applications on the Force dot Com platform back then.
Speaker 1: So our goal, our mission for this deep dive, it's
Speaker 1: really to pull out those core blueprints, those patterns.
Speaker 2: Yeah, the essential ideas, the how to from that era.
Speaker 1: And figure out, okay, why did this stuff matter back then?
Speaker 1: And importantly for you listening, what enduring value is there?
Speaker 1: What can we still learn from it today? Does it
Speaker 1: still hold up?
Speaker 2: That's right? And we're grounding this whole discussion in this
Speaker 2: packbook by Steven Moss. This guy, Stephen, he was a
Speaker 2: Force dot Com developer, certified admin to with like over
Speaker 2: twenty years in it.
Speaker 1: Wow, twenty years even back then, Yeah.
Speaker 2: Going way back. He programmed on a Commodore sixty four
Speaker 2: and his background was super diverse. CRM sure, but also
Speaker 2: gis manufacturing even early mobile dev the book mentions he
Speaker 2: still had a palm pilot.
Speaker 1: Sleigh chuckle, a palm pilot. Yeah, that really paints a
Speaker 1: picture of the tech landscape, then, doesn't it.
Speaker 2: It absolutely does. And importantly, this wasn't just you know,
Speaker 2: one guy's opinion. The book had several experience reviewers too,
Speaker 2: people with deep backgrounds in Salesforce, architecture, consulting various IT fields.
Speaker 1: Okay, so it's grounded in real world practice, not just.
Speaker 2: Theory, exactly practical hands on experience from that time. And yeah,
Speaker 2: the specific versions of sales coorse features they're from twenty fourteen.
Speaker 2: But the underlying approach, how they use the platform's building blocks, objects, code,
Speaker 2: integration points, that's what's really insightful, I think.
Speaker 1: Right, So let's dive into that first blueprint the book
Speaker 1: lays out. It tackles a pretty fundamental challenge, how do
Speaker 1: you build those external facing websites or maybe communities that
Speaker 1: are tightly integrated with through Force dot com data.
Speaker 2: Right, And this blueprint it really leverages what were key
Speaker 2: features for this back then, communities Incite dot com. The
Speaker 2: main idea was using these native platform tools, you could
Speaker 2: expose you know, select Force dot com data and processes
Speaker 2: to people outside.
Speaker 1: Your org without needing a whole separate database or tons
Speaker 1: of complex infrastructure.
Speaker 2: Right exactly. It simplified things quite a bit.
Speaker 1: And the book walks through a specific example setting up
Speaker 1: this Force Volunteers community. So sorts of the basics the setup.
Speaker 1: Get to enable communities in your org the first that,
Speaker 1: and create the specific community instance itself to find the
Speaker 1: Force dot Com objects they'll interact with, like the use
Speaker 1: of volunteer event custom object.
Speaker 2: Example, right, the data structure underneath, and.
Speaker 1: Then crucial details like setting up specific user profiles they
Speaker 1: mentioned a volunteer community user profile and getting those permissions
Speaker 1: just right often read only access to things like accounts, contacts,
Speaker 1: and those volunteer events.
Speaker 2: Yeah, that's set up. Part is critical. It defines the
Speaker 2: data model and exactly who gets to see what. But
Speaker 2: the really interesting bit, I think is how they actually
Speaker 2: built the look and feel of the public site. Okay,
Speaker 2: the blueprint uses site dot com Studio, which was this
Speaker 2: visual design tool. Think of it like well, kind of
Speaker 2: a precursor to modern drag and drop.
Speaker 1: Builders made a visual page building.
Speaker 2: Yeah, letting you assemble pages using components things like header
Speaker 2: and footer widgets. You could manage assets like images, logos
Speaker 2: right there in Salesforce, and you could customize the branding visually,
Speaker 2: down to setting color schemes with like HDML color codes.
Speaker 1: Right. But it wasn't just about making static pages look nice.
Speaker 1: The real power came from embedding live data. Yeah, totally.
Speaker 2: The blueprint shows how you could like drag a data
Speaker 2: table component onto an events page, point it at that
Speaker 2: volunteer event custom object you set.
Speaker 1: Up, and boom, there's your list of events.
Speaker 2: Exactly, pulled straight from your Salesforce data live. And you
Speaker 2: could configure filtering as ordering right thereinthsite dot com editor
Speaker 2: like show events sorted by start day, ascending order that
Speaker 2: kind of thing. Ic and security making sure only the
Speaker 2: right people see certain.
Speaker 1: Pages, yeah, that was handled too. You could secure pages
Speaker 1: with a simple setting. The book mentions a padlock icon
Speaker 1: appearing so certain content only visible to logged in community members.
Speaker 1: You could even add personalized elements like maybe a chatterfeed
Speaker 1: showing stuff relevant to the logged in volunteer on their
Speaker 1: profile page.
Speaker 2: So the big takeaway from this first blueprint it's really
Speaker 2: that even a decade ago, the platform offered these pretty
Speaker 2: robust built in tools, tools that let you go from
Speaker 2: just an internal data model to a full on, branded,
Speaker 2: data driven external site with user management security.
Speaker 1: Yeah, and it's significantly lowered the barrier to entry, didn't
Speaker 1: it compared to building all that from scratch with traditional webstacks.
Speaker 1: Abstracted away a lot of the back end headache.
Speaker 2: That's a great point. Okay, shifting gears now completely different,
Speaker 2: direc The sources also lay out a blueprint for an
Speaker 2: e commerce solution. But this isn't just building order forms
Speaker 2: inside Salesforce.
Speaker 1: No, this is different. This is about using Force dot
Speaker 1: com as the back end system for an external online store.
Speaker 2: And they use a fun example, a fictional company selling
Speaker 2: like high performance racing car engines.
Speaker 1: Nice.
Speaker 2: The approach starts, you know where it usually does, defining
Speaker 2: the data model within Force dot com. So custom objects
Speaker 2: like order orderline item maybe for the engine types, and
Speaker 2: order line for these specific items in a.
Speaker 1: Particular order, right the core data structure.
Speaker 2: And the blueprint gets pretty specific about configuring the fields,
Speaker 2: setting up the right field types, number, picklist, currency, and
Speaker 2: defining the relationships like lookups or master detail between these objects.
Speaker 1: Now, why is that level of detail on field types
Speaker 1: and names so critical in this specific blueprint.
Speaker 2: Ah, because the crucial piece here isn't just the Force
Speaker 2: dot Com side, it's the integration. This whole solution depends
Speaker 2: heavily on an external e commerce website talking to Salesforce,
Speaker 2: and for that connection that API communication to work smoothly.
Speaker 2: The data structure, the field types, even the exact field
Speaker 2: names Inforce dot Com. They need to align precisely with
Speaker 2: what the external application expects when it's sending or asking
Speaker 2: for data. Any mismatch causes problems.
Speaker 1: Ah, got it, That makes perfect sense. So this external site,
Speaker 1: where does it live? What's powering it?
Speaker 2: This is where Heroku comes into the picture. Remember, Salesforce
Speaker 2: had acquired Heroku a few years before twenty fourteen. So
Speaker 2: the book highlights Heroku as the platform for hosting this
Speaker 2: external store, okay, and it emphasizes Heroku's polyglot nature, you know,
Speaker 2: its ability to run apps written in different languages like
Speaker 2: Ruby on Rails, Java, no JS, Python gives developers flexidadity.
Speaker 1: So the blueprint details setting up that dev environment like
Speaker 1: installing node Rubyon, Rails.
Speaker 2: Yep exactly, mentions minimum versions, installing get and crucially, it
Speaker 2: walks through configuring a Force dot Com remote act access
Speaker 2: application in.
Speaker 1: That remote access app. That's the key for the secure connection,
Speaker 1: the handshake between Heroku and Forest dot Com.
Speaker 2: Precisely, that's how the external Heroku app gets the owooth credentials.
Speaker 2: It needs the consumer key and secret that lets it
Speaker 2: connect securely to the Force dot Com API and actually
Speaker 2: access the data, create records, et cetera.
Speaker 1: Okay, and the example uses Ruby on Rails for the
Speaker 1: external site.
Speaker 2: Yeah, the example build is in Rails and it uses
Speaker 2: a library called the Force dot rb rubygem. The book
Speaker 2: describes it as a nice wrapper around the Force dot
Speaker 2: Com rest API. Basically, it simplifies making those API calls
Speaker 2: from Ruby to do things like create order records in
Speaker 2: Salesforce or look up product info stored there.
Speaker 1: So let's trace the flow. A customer goes to the
Speaker 1: external site on Heroku. They place an order for a
Speaker 1: racing engine. That Rails app uses the Force dot RBGM
Speaker 1: and the off credentials to talk to the Force dot
Speaker 1: Com rest.
Speaker 2: API and creates the order order line item order line
Speaker 2: records inside Salesforce.
Speaker 1: Okay, so the order data lands Inforce dot Com. What
Speaker 1: happens then? Who handles it?
Speaker 2: Right? So? Now Force dot Com shifts into being the
Speaker 2: fulfillment and management system. The blueprint includes building an internal
Speaker 2: fulfillment application within Force dot com itself using APEX controllers
Speaker 2: and visual Force pages.
Speaker 1: Ah, so internal users log into Salesforce exactly.
Speaker 2: They log into this custom fulfillment app. They can search
Speaker 2: for new orders that came in from the external site,
Speaker 2: manage the order status, handle the shipping, the whole fulfillment process.
Speaker 1: Gotcha. So the core insight here pretty powerful. This blueprint
Speaker 1: really shows Force dot com not just as a place
Speaker 1: to build apps, but as a kind of robust, secure
Speaker 1: data hub and process engine for applications build anywhere else
Speaker 1: on totally different textacts connected via APIs.
Speaker 2: Yeah, and that pattern using Salesforce as a back end
Speaker 2: service that's arguably even more relevant today, isn't it in
Speaker 2: our whole micro services API first world?
Speaker 1: Absolutely. It really demonstrates the platform's flexibility beyond just its
Speaker 1: own native UI. Okay, let's pivot again. Let's go to
Speaker 1: a more class CRM scenario. The sources give a detailed
Speaker 1: blueprint for a student admission system for fictional Force University.
Speaker 1: This sounds like building a comprehensive, process driven application entirely
Speaker 1: within Force dot Com. Yeah.
Speaker 2: This is a great example of building out complex business
Speaker 2: logic using mostly native platform capabilities, and it starts as
Speaker 2: you'd expect with a solid data model. You need to
Speaker 2: track everything related.
Speaker 1: To admissions, so custom objects.
Speaker 2: Right, custom objects like course applicant and course application, and
Speaker 2: they get into the field specifics again using dependent picklists,
Speaker 2: maybe for course details. Marking certain applicant fields is required
Speaker 2: given name, surname, date of birth, address.
Speaker 1: All that core info, and probably a status field for
Speaker 1: the application itself.
Speaker 2: Definitely a picklist for application status on the course application
Speaker 2: object with values tracking the whole life cycle new under assessment,
Speaker 2: closed admit applicant, closed reject applicant, things like that.
Speaker 1: Makes sense now beyond just storing the data the system,
Speaker 1: like admission, it needs really careful management of who can
Speaker 1: see what and how these applications actually move through the process.
Speaker 2: Absolutely, access control and workflow automation are central here. The
Speaker 2: blueprint outlines setting up different profiles, maybe one for course administration,
Speaker 2: one for the admissions office staff, one for selection officers
Speaker 2: who make the decisions, and also a role hierarchy that
Speaker 2: mirrors the university structure, you know, president at the top
Speaker 2: down through dean's managers, officers.
Speaker 1: And that combination of profiles and roles lets you control
Speaker 1: permissions very.
Speaker 2: Granularly, exactly granular control over object access, field level security.
Speaker 2: Making sure users only see and edit the data that's
Speaker 2: relevant to their specific role in the whole admissions process,
Speaker 2: keeps things secure and focused.
Speaker 1: Okay, that covers access. What about the process automation? How
Speaker 1: does an application automatically move from say new to under
Speaker 1: assessment and get assigned to the right team or person.
Speaker 2: Ah, this is where they combine configuration and code quite cleverly.
Speaker 2: I thought the blueprint uses cues standard Salesforce cues OKA.
Speaker 2: Maybe one queue for the business faculty admissions team, one
Speaker 2: for the science faculty, perhaps an exception queue for applications
Speaker 2: that need special handling. These cues act as holding bins
Speaker 2: for the applications.
Speaker 1: And how does the system know which queue to send
Speaker 1: an application to based on the course they applied for?
Speaker 2: Precisely? And they even suggest using custom settings remember those
Speaker 2: to create a mapping. You'd map specific faculties or courses
Speaker 2: to their corresponding quids in the custom settings.
Speaker 1: Oh that's smart. So the routing destination becomes configurable without
Speaker 1: needing to change code later.
Speaker 2: Exactly makes it more maintainable.
Speaker 1: So you set up the queues, you set up the
Speaker 1: mapping and custom settings, but how does the system automatically
Speaker 1: perform the routing when a new application comes in? What
Speaker 1: triggers that?
Speaker 2: That piece is handled by an APEX trigger. The blueprint
Speaker 2: implements the core routing logic in a before insert trigger
Speaker 2: on the course application object.
Speaker 1: Before insert, so it fires before the new application record
Speaker 1: is actually.
Speaker 2: Saved yep, before it hits database. The trigger logic looks
Speaker 2: at the course the applicant applied for it, queries those
Speaker 2: custom settings to find the correct faculty QID based on
Speaker 2: the mapping, and.
Speaker 1: Then it sets the owner reed field on the new
Speaker 1: course application record to that qid exactly.
Speaker 2: So the moment the record is saved, it's already assigned
Speaker 2: to the correct queue, ready for that team to pick
Speaker 2: it up.
Speaker 1: Wow, that's a really neat pattern. You're using clicksnot code
Speaker 1: for the queues and the configurable mapping, but then a
Speaker 1: targeted piece of APEX code for the dynamic routing logic
Speaker 1: based on that configuration. That's a great aha moment showing
Speaker 1: how those different platform tools work together. For pre sophisticated automation.
Speaker 2: It really is, and they didn't stop just at routing.
Speaker 2: The blueprint also included a user experience enhancement, a decision entry.
Speaker 1: Publisher action would you like a quick action today?
Speaker 2: Yeah, basically a quick action. This was placed right on
Speaker 2: the course application record page, probably in the chatter feed.
Speaker 2: It let a selection officer quickly pop open a little form,
Speaker 2: enter their disis, admit, reject, add some notes, update the
Speaker 2: status field.
Speaker 1: All directly from the context of that record's.
Speaker 2: Feed exactly, and it would automatically generate a chatter posting,
Speaker 2: decision entered, admit, or whatever super streamline for that common task,
Speaker 2: and it kept everyone collaborating on that record informed right
Speaker 2: there in the feed.
Speaker 1: Nice. So this blueprint it really showcases building these complex
Speaker 1: human centric business processes and to end on the platform
Speaker 1: using that mix of declarative tools and code where needed.
Speaker 2: Definitely, and they mentioned potential next steps too, like adding
Speaker 2: an approvals process or workflows to automatically email applicants their results.
Speaker 2: You can see how you'd layer more automation on top.
Speaker 1: Okay, shifting focus again. Reporting can't run a business or
Speaker 1: university without good reporting. The source even quotes that classic
Speaker 1: line if you cannot measure it, you cannot improve it.
Speaker 2: A fundamental truth.
Speaker 1: But this blueprint it's not really about standard salesforce reports
Speaker 1: and dashboards, is it. It's about building custom reporting capabilities.
Speaker 2: Exactly when the standard out of the box reporting tools
Speaker 2: maybe don't give you the specific calculations, the specific layout,
Speaker 2: or maybe the performance you need.
Speaker 1: And the example they use is an executive information system
Speaker 1: an EIS dashboard for a fictional force majure insurance brokers.
Speaker 1: Sound serious?
Speaker 2: Yeah, The goal was to provide those specific aggregated key
Speaker 2: performance indicators KPIs that executives need at a glance, things
Speaker 2: that might require complex calculations or pulling data together in
Speaker 2: ways standard reports struggle with.
Speaker 1: Okay, So how do they approach building that custom reporting
Speaker 1: engine on force dot com? Where does it start?
Speaker 2: Well, like the others, it starts with the data model
Speaker 2: required for the report itself. They outline custom objects like
Speaker 2: EIS policy to hold the core insurance policy data, and
Speaker 2: another object called EIS dashboard.
Speaker 1: An EIS dashboard object, what's that for?
Speaker 2: The book suggests that in a real production environment you
Speaker 2: might use something like analytical snapshots scheduled jobs that capture
Speaker 2: aggregated overtime to populate this EIS dashboard object, so it
Speaker 2: holds the historical trend data needed for the dashboard.
Speaker 1: Ah okay, a way to snapshot results for performance and
Speaker 1: trending exactly.
Speaker 2: And then they detail adding the specific fields needed on
Speaker 2: the EIS policy object, things like policy date, policy type
Speaker 2: like auto home life, policy amount, whether it's a renewal,
Speaker 2: the renewal date, all the raw data points the customer
Speaker 2: report wanted to crunch.
Speaker 1: So you've get the data structure defined. Where does the
Speaker 1: custom logic the calculation engine actually live.
Speaker 2: That's handled primarily by an APEX controller paired with a
Speaker 2: visual force page for the display. The APEX controller is
Speaker 2: really the brains of this operation.
Speaker 1: Okay.
Speaker 2: It defines properties to hold the filtering criteria the user
Speaker 2: selects on the page like a start an end date range,
Speaker 2: maybe filter by policy type. And importantly it has properties
Speaker 2: to store the final calculated KPI values that will be displayed.
Speaker 1: And does the controller handle getting the filter options too,
Speaker 1: like the lurk of policy type.
Speaker 2: Yeah, and there's a neat detail mention. The controllers constructor
Speaker 2: can dynamically populate the options for the policy type. PICKLST
Speaker 2: filter on the page It does this by introspecting the
Speaker 2: schema of the es policic object using apex code schema
Speaker 2: dot pickless entry, so if you add a new policy
Speaker 2: type later, it automatically shows up as a filter option.
Speaker 1: Oh that's nice. Dynamic picklists based on schema are always
Speaker 1: good for maintainability avoids hard coding. So what kind of
Speaker 1: logic is running inside that controller? To actually calculate the KPIs.
Speaker 2: The core methods execute aggregate socle queries. This is where
Speaker 2: you leverage the power of the Force dot com database
Speaker 2: engine directly from apex.
Speaker 1: So using sum count, group by backay exactly.
Speaker 2: They use socle functions like some policy amount or counted
Speaker 2: to aggregate data from that EIS policy object. They apply
Speaker 2: filters based on the user's selected date range and policy
Speaker 2: type using wear clauses. Sometimes they group by policy type
Speaker 2: or date periods.
Speaker 1: And the apex code then takes those raw aggregated results.
Speaker 2: From SOCO and performs the final calculations to derive the
Speaker 2: specific KPIs. The business needs things like you know, total
Speaker 2: renewals amount, renewal success rate percentage, which might involve comparing
Speaker 2: counts number of new policies. One maybe policy growth percentage
Speaker 2: compared to a previous period.
Speaker 1: Got it. So SOCLE does the heavy lifting on aggregation,
Speaker 1: APIX does the final math in business logic, and the
Speaker 1: Visual Force page is the presentation layer showing this all
Speaker 1: to the executive YEP.
Speaker 2: The Visual Force page eis dashboard page dot page provides
Speaker 2: the user interface. It's got the input fields for selecting
Speaker 2: the date, range and policy type filter, a command button
Speaker 2: that tells the APEX controller to run the calculations.
Speaker 1: And then displays the results.
Speaker 2: Right. It displays those calculated KPI values using components like
Speaker 2: apex dot output text, and they mention using formatting masks
Speaker 2: within the Visual Force to display currency or percentages correctly
Speaker 2: like hashtag date zero zero zero zero.
Speaker 1: Makes sense for a clean look.
Speaker 2: And the blueprint also mentions including visual Force chart components
Speaker 2: APAX dot chart to actually visualize some of this data,
Speaker 2: not just show numbers.
Speaker 1: And they point out a couple of technical details using
Speaker 1: read only true on the Visual Force page and setting
Speaker 1: doc type HTML five point zero. Why call those out?
Speaker 2: Well, read only true was and still is a significant
Speaker 2: performance optimization for visual force pages that don't need to
Speaker 2: maintain component view state between server requests. If your page
Speaker 2: is just displaying data calculated by the controller. Using read
Speaker 2: only true can make it load noticeably faster because the
Speaker 2: server doesn't have to serialize and de serialize that view state.
Speaker 1: Okay, good performance tip, and the doc type.
Speaker 2: Setting doc type HTML five point zero just ensures the
Speaker 2: page renders using modern HTML five standards, which was becoming
Speaker 2: the standard around twenty fourteen. Helps with browser compatibility and
Speaker 2: using newer HTML features if needed.
Speaker 1: So this blueprint is a great example of how when
Speaker 1: standard reports hit their limits, developers could roll up their
Speaker 1: sleeves and use APEX and Visual Force to build highly customized,
Speaker 1: potentially complex, data heavy dashboards directly on the platform, leveraging
Speaker 1: its database power and programmatic control.
Speaker 2: Absolutely, it really highlights that flexibility for bespoke reporting needs.
Speaker 1: Okay, now let's talk mobile. The mobile revolution was definitely
Speaker 1: in full swing by twenty fourteen. Salesforce one had launched,
Speaker 1: so the sources dive into building mobile applications using the
Speaker 1: Salesforce Mobile SDK.
Speaker 2: Yeah, they had to address mobile, and they start by
Speaker 2: outlining the main approaches you could take back then three
Speaker 2: main paths. One was building pure HTML five web apps
Speaker 2: designed to run well in a mobile browser. Or within
Speaker 2: the Salesforce one container. Second was hybrid apps, typically using
Speaker 2: a patche cordova, which lets you wrap your web code HTML, CSS,
Speaker 2: JavaScript inside a native app shell, giving you access to
Speaker 2: some device features.
Speaker 1: Right like a web app pretending to be a native app.
Speaker 2: Kind of yeah. And the third path was fully native
Speaker 2: apps using the specific Salesforce mobile SDKs for iOS and
Speaker 2: Android to build apps using objective C, Swift or Java.
Speaker 1: In which path does this blueprint focus on?
Speaker 2: This specific blueprint digs primarily into the HTML five approach,
Speaker 2: which was pretty popular because it let web developers leverage
Speaker 2: their existing skills HTML, JavaScript's CSS to build mobile experiences
Speaker 2: connected to Salesforce relatively quickly.
Speaker 1: So htail five mobile apps. What kind of web technologies
Speaker 1: are they combining here? In this blueprint?
Speaker 2: The core idea was building these things called single page
Speaker 2: applications or spas, where most of the UI and logic
Speaker 2: runs in the browser using JavaScript. The blueprint specifically mentions
Speaker 2: using Angular JS, which was a really popular JavaScript framework
Speaker 2: back then maintained by Google well suited for this kind
Speaker 2: of model view controller NBC architecture in the front end.
Speaker 1: Okay, angular JS? What else?
Speaker 2: They also leverage Twitter Bootstrap for the UI components and
Speaker 2: making the layout responsive so it looked okay on phones
Speaker 2: and tablets without writing tons of custom CSS.
Speaker 1: Bootstraps still around very useful.
Speaker 2: And jQuery, which was pretty much ubiquitous back then and
Speaker 2: also a dependency for some of the Salesforce Mobile SDK's
Speaker 2: JavaScript libraries.
Speaker 1: So you've got Angular Bootstrap, jQuery running as an HTML
Speaker 1: five app. How does it actually connect to Salesforce data
Speaker 1: and handle authentication?
Speaker 2: That's where the Salesforce Mobile SDK libraries come in. The
Speaker 2: blueprint details setting up the application files, including downloading a
Speaker 2: specific Salesforce Angular JS mobile pack they provided back then, okay.
Speaker 1: A specific pack for Angular integration.
Speaker 2: Yeah, and key parts involved initializing the Angular JS app
Speaker 2: correctly and wiring it up with the SDK's JavaScript libraries,
Speaker 2: things like Angularforce, dot JS, Force Attk dot Mobile SDKJS.
Speaker 2: These libraries handled.
Speaker 1: The hard parts looked like authentication exactly.
Speaker 2: The blueprint explains the authentication flow, which relied on Angular
Speaker 2: JS controllers managing the Salesforce OS process, you know, initiating
Speaker 2: the log in, handling the callback from Salesforce with the
Speaker 2: access token, storing token securely, refreshing them when needed and
Speaker 2: redirecting users once they were logged in. The SDK libraries
Speaker 2: provided functions to help with all that.
Speaker 1: Okay, so the users authenticated, the framework is set up up,
Speaker 1: how do you actually get the business data, like say,
Speaker 1: catching opportunity records to display in the mobile app.
Speaker 2: This is where they show a common pattern from the
Speaker 2: Angular JS world, creating something called an opportunity factory a factory.
Speaker 2: In Angular terms, a factory was basically a reusable service,
Speaker 2: a chunk of code designed to interact with the Salesforce
Speaker 2: data via the SDK's helper functions. So this opportunity factory
Speaker 2: would have methods like get less opportunities, get opportunity details, opportunity.
Speaker 1: At standard CRD like operations.
Speaker 2: Pretty much, but here's where it gets especially interesting. The
Speaker 2: factory also had a method like get opportunities nearby latitude,
Speaker 2: longitude radius.
Speaker 1: Wait, hang on, the mobile app can query Salesforce for
Speaker 1: records based on geographic location. How does that work? That
Speaker 1: sounds pretty advanced for twenty fourteen.
Speaker 2: It was pretty cool. It leveraged a specific soacole query
Speaker 2: capability called geolocation and distance, but it required some significant
Speaker 2: setup on the back end and Salesforce.
Speaker 1: First, okay, what kind of setup.
Speaker 2: Well, first, to even store location data, the blue print
Speaker 2: shows adding a new field to the account object in salesforce,
Speaker 2: a field of the geolocation data type, which stores latitude
Speaker 2: and longitude coordinates.
Speaker 1: Right, you need somewhere to put the coordinates. Yeah, but
Speaker 1: how do those coordinates get into that field? Accounts usually
Speaker 1: just have billing addresses.
Speaker 2: Ah, good question. They don't magically appear. This required more work.
Speaker 2: It required code APEX again. Yep, the blueprint includes an
Speaker 2: APEX utility class and crucially, an APEX trigger. This trigger
Speaker 2: fired whenever an account record was inserted or updated.
Speaker 1: And what does the trigger do?
Speaker 2: It automatically made an HTTP call out from APEX to
Speaker 2: an external service, specifically the Google geocoding API. It sent
Speaker 2: the account's billing address, street, city, state ZIP to Google.
Speaker 1: And Google's API sent back the latitude and longitude for
Speaker 1: that address exactly.
Speaker 2: The APEX trigger then took those coordinates returned by Google
Speaker 2: and saved them into that new geolocation field on the
Speaker 2: account record.
Speaker 1: Wow. Okay, hold on, so they're using an APEX You're
Speaker 1: firing on save to make a real time web service
Speaker 1: call out to an external api. Google just to enrich
Speaker 1: the Salesforce data with coordinates before the mobile app even
Speaker 1: tries to query base on location. That's quite a bit
Speaker 1: of back end automation just to enable that one mobile feature.
Speaker 2: It absolutely is, and it wasn't trivial to set up.
Speaker 2: It required configuring a remote site setting in Salesforce to
Speaker 2: allow APEX to make calouts to the Google Api endpoint.
Speaker 2: And you need to get a Google API key which
Speaker 2: might have had usage limits or.
Speaker 1: Costs, right external dependencies. So, once all that back end
Speaker 1: work is done, the geofield exists, the trigger is firing,
Speaker 1: accounts are getting geocoded, and how does the mobile app
Speaker 1: use it?
Speaker 2: Okay, So now the mobile app, using an Angular JS
Speaker 2: controller to call it. An opmap controller in the example
Speaker 2: could first get the user's current location from the device's GPS.
Speaker 1: Using browser geolocation APIs or Cordova plugins probably yeah.
Speaker 2: Then, armed with the user's current lat long, that controller
Speaker 2: could call the get opportunities nearby method in the op
Speaker 2: Portunity factory.
Speaker 1: And that factory method would use the Salesforce Mobile.
Speaker 2: SDK to construct a specific soacle query using the distance function,
Speaker 2: something like select name from opportunity where distance account location
Speaker 2: lacktuon uger lab user lawn my five searching for opportunities
Speaker 2: linked to accounts whose location field is within say five
Speaker 2: miles of the user's current.
Speaker 1: Location, and Salesforce handles that spatial query on the back
Speaker 1: end using the index geolocation field.
Speaker 2: Then the results come back to the mobile app, and
Speaker 2: the outmap controller could take that list of nearby opportunities
Speaker 2: and display them as markers on an embedded Google Map
Speaker 2: within the HTML five app.
Speaker 1: That is, that's a really impressive end to end scenario.
Speaker 1: It perfectly demonstrates building a truly context a wear location
Speaker 1: based mobile experience, but it involves combining front end web tech,
Speaker 1: Angular bootstrap maps, the mobile SDK for data access, and
Speaker 1: off significant back end APEX automation for data enrichment and
Speaker 1: integration with external APIs like Google goocode shows all the
Speaker 1: layers you might need.
Speaker 2: It really does. It brings home that idea of Force
Speaker 2: dot com as a platform you build on leveraging all
Speaker 2: its pieces, not just in the standard UI, and the
Speaker 2: blueprint also briefly touches on setting up the native Android
Speaker 2: SDK using the forstraid command, hinting at that alternative path too.
Speaker 1: Fascinating stuff. Okay, one final blueprint. This one takes the
Speaker 1: idea of external integration even further. It's about connecting a
Speaker 1: Force dot Com application to another major cloud platform, specifically
Speaker 1: Microsoft Windows Azure.
Speaker 2: Yeah, this one pushes the integration boundary, and the particular
Speaker 2: Azure service they explore is Azure Notification Hubs.
Speaker 1: Notification HUBS so for sending push notifications to mobile.
Speaker 2: Apps, exactly as your Notification Hubs was and is Microsoft
Speaker 2: service designed to simplify sending mobile push notifications reliably across
Speaker 2: all the different platforms iOS, APNS, Android, GCMFCM, Windows devices,
Speaker 2: all through a single unified rest API.
Speaker 1: As it abstracts away the complexity of talking directly to
Speaker 1: apples and Google's push.
Speaker 2: Services precisely that was the big value prop handles, load balancing, queuing,
Speaker 2: device registration management, all that complexity for you.
Speaker 1: So this blueprint is about using Force dot Com to
Speaker 1: initiate sending push notifications out to mobile apps, potentially apps
Speaker 1: built using the Salesforce Native SDK, but leveraging Azure as
Speaker 1: the delivery mechanism.
Speaker 2: You got it. And this blueprint actually assumes you're working
Speaker 2: with a native Android application, one built using the Salesforce
Speaker 2: Android Native Mobile SDK, unlike the previous Ashmel five example.
Speaker 1: Okay, so native Android this time. Yeah.
Speaker 2: The setup section details getting the Android Developer Tools ADT bundle,
Speaker 2: setting up an Android Virtual Device add for testing, and
Speaker 2: installing the Salesforce Android Native Mobile SDK using that four
Speaker 2: stroid command line tool we mentioned, and of course configuring
Speaker 2: the Salesforce Connected app with the right otooth settings for
Speaker 2: a native mobile app.
Speaker 1: Flow makes sense. What about the setup needed on the
Speaker 1: Azure side.
Speaker 2: On the Azure side, you first need to interact with
Speaker 2: Google Cloud Messaging GCM which is now Fire Based Cloud
Speaker 2: Messaging FCM, to get an API project number and an
Speaker 2: API key. Azure needs these credentials to be allowed to
Speaker 2: send notifications via Google's infrastructure to Android devices.
Speaker 1: Ok to yeah, the Google keys.
Speaker 2: Then you can figure the Azure notification hub itself within
Speaker 2: the Azure portal. You create a name space, then create
Speaker 2: a hub within that name space, and critically, you link
Speaker 2: that hub to your GCMAPI key so Azure knows how
Speaker 2: to talk to Google for your app. You also need
Speaker 2: to grab your Azure Service Bus credentials, specifically an endpoint
Speaker 2: URL and an access key.
Speaker 1: All right, So quite a bit of setup on both
Speaker 1: Salesforce Android and Azure Google fronts. Now you have the
Speaker 1: native Android app potentially ready to receive notifications and Azure
Speaker 1: is configure to send them via GCM. Howdes Force dot
Speaker 1: Com actually trigger Azure to send a message? That's the
Speaker 1: core in creation right.
Speaker 2: That is the core, and it happens via apex code
Speaker 2: making callouts from Force dot Com directly to the Azure
Speaker 2: notification hubs rest API.
Speaker 1: Okay, Apex again talking do external RESTSPI exactly.
Speaker 2: The blueprint details building a set of apex classes that
Speaker 2: effectively act as a rapper or an interface to the
Speaker 2: Azure and Notification hubs API. These classes contain key methods
Speaker 2: to like what first a method to get an Azure
Speaker 2: access token Back in twenty fourteen, Azure notification hubs often
Speaker 2: use something called OWR app for authentication, which was a
Speaker 2: specific token exchange protocol. It involved making an http PST
Speaker 2: request from Apex to a specific Azure ooth wr at endpoint,
Speaker 2: sending your Azure credentials like the default issuer and a
Speaker 2: default t from your service bus.
Speaker 1: Credential, and that calla would need a remote site setting
Speaker 1: in Salesforce right to allow Apex to call the Azure.
Speaker 2: Endpoint absolutely required a remote site setting. The response gave
Speaker 2: you a short lived access token. Second, maybe a method
Speaker 2: to query Azure to get a list of existing device
Speaker 2: registrations associated with your notification hub. See which mobile users
Speaker 2: have actually registered their devices with Azure.
Speaker 1: Okay, so you can see who's listening yep.
Speaker 2: And third, the most crucial step, the method to actually
Speaker 2: send a message through the notification hub. This involved making
Speaker 2: another http PST request from Apex, this time to the
Speaker 2: notification hub's main rest API endpoint, which needed another remote
Speaker 2: site setting for the hub's namespace RL.
Speaker 1: And what goes in that post request.
Speaker 2: You'd include the Azure access token you obtained earlier. In
Speaker 2: the authorization header, you'd specified target tags. Azure notification hubs
Speaker 2: uses tags for targeting. A common pattern was to have
Speaker 2: the mobile app register itself with Azure using the Salesforce
Speaker 2: user idea as a tag. So from Apex you could
Speaker 2: target the message to a specific Salesforce user ID tag.
Speaker 2: And of course you include the actual message payload you
Speaker 2: want to send in the request body.
Speaker 1: Wow. Okay, so Apex is potentially making one cal out
Speaker 1: to get an Azure token. Maybe another to query registrations,
Speaker 1: and then a third cal out to actually send the
Speaker 1: notification payload to a specific tag via the Azure rest API.
Speaker 1: This sounds pretty intricate, a multi step cloud to cloud integration.
Speaker 2: It is definitely intricate, but it highlights the platform's capability
Speaker 2: back then to perform these complex server to server integrations
Speaker 2: directly interacting with other major cloud providers. APIs right from
Speaker 2: within apex code.
Speaker 1: Okay, so Apex handles the back end communication with Asher.
Speaker 1: How does a regular Salesforce user initiate this? They don't
Speaker 1: write apex right.
Speaker 2: So the final piece of the blueprint is building a
Speaker 2: simple user interface within Force dot com a visual Force
Speaker 2: page and a supporting.
Speaker 1: Apex controller, and what does his page let them do?
Speaker 2: This UI would allow a Salesforce user, maybe a support
Speaker 2: agent or a manager, to say, select which registered mobile
Speaker 2: user they want to send a message to. The picklist
Speaker 2: of users could be populated by querying Salesforce user records
Speaker 2: whose user IDs match the registration tags retrieved from Azure.
Speaker 2: Using that second Apex method we talked about clever, so
Speaker 2: you only show users who actually have the app registered exactly.
Speaker 1: And then there'd be a text box to type the
Speaker 1: message content. When the Salesforce user clicks a send message
Speaker 1: button on the visual Force page.
Speaker 2: The controller calls that third APEX method, which makes the
Speaker 2: call out to the Adjure Notification Hub rest API, passing
Speaker 2: the selected user ID tag and the message text precisely.
Speaker 1: Azure then takes over, finds the device registered with that
Speaker 1: tag and sends the push notification via Google's GCMFCM infrastructure
Speaker 1: to the user's Android device.
Speaker 2: That's a very sophisticated blueprint. It really demonstrates a complex
Speaker 2: cloud to cloud integration pattern. Plus the cloud to mobile piece,
Speaker 2: all orchestrated and initiated from within Force dot Com shows
Speaker 2: its potential as a central command center for these kinds
Speaker 2: of connected applications.
Speaker 1: Absolutely, it ties a lot of different pieces together, native
Speaker 1: mobile SDK, apex colouts, external cloud services, visual Force UI.
Speaker 1: So let's try and wrap this deep dive up. We've
Speaker 1: looked at these six predistinct blueprints from this twenty fourteen
Speaker 1: book building communities, e commerce, back ends, internal CRM processes,
Speaker 1: custom reporting, mobile apps, cloud integrations. What's the big picture
Speaker 1: takeaway when you look back at all of them.
Speaker 2: Well, the clear picture that emerges, I think is that
Speaker 2: Force dot Com even a decade ago, was being presented
Speaker 2: and used as a really highly capable, very adaptable platform.
Speaker 2: It wasn't just for building standard CRM screens. It could
Speaker 2: do much more.
Speaker 1: Yeah, you see it being used for external engagement with
Speaker 1: those communities and site dot com tools acting. Is that
Speaker 1: robust back end, data store and API layer for totally
Speaker 1: external systems like that e commerce site running on heroco.
Speaker 2: Right, the headless pattern almost.
Speaker 1: Powering complex internal business processes with automation like the student
Speaker 1: admissions example. Yet workflow in logic, delivering custom beta heavy
Speaker 1: reporting dashboards when the standard ones weren't.
Speaker 2: Enough, going beyond standard reports.
Speaker 1: Building quite sophisticated mobile experiences using the SDK, including location.
Speaker 2: Awareness, leveraging device capabilities, and even acting as the orchestrator
Speaker 2: for integrations with other major cloud services like as your
Speaker 2: notification humps. Yeah, connecting the clouds across all these different scenarios.
Speaker 2: You see the same or platform elements being used in
Speaker 2: different ways.
Speaker 1: You really do you see custom objects providing that flexible
Speaker 1: data layer underneath everything. Yeah, you see profiles, permissions rolls
Speaker 1: handling the security aspect. You see APEX and visual force
Speaker 1: popping up for custom logic, custom UI and especially for
Speaker 1: those crucial integrations, and maybe most importantly, you see the
Speaker 1: APIs and the SDKs acting as the doorways, the way
Speaker 1: to connect Force dot Com outwards to other systems or
Speaker 1: to build entirely new experiences like mobile apps on top
Speaker 1: of it.
Speaker 2: Exactly the platform's strength, even back then, seems to be
Speaker 2: rooted in that rapid application development capability, handling the infrastructure
Speaker 2: burden for you, while still providing those essential hooks, those
Speaker 2: integration points you needed to extend it and connect it
Speaker 2: to the wider world.
Speaker 1: It's really fascinating to see how these patterns, these blueprints
Speaker 1: for integration, for process automation, for leveraging mobile, for connecting clouds,
Speaker 1: how they're being defined and implemented using the specific tools
Speaker 1: and features available on the PLATF in twenty fourteen.
Speaker 2: It really is you can see the foundation being laid
Speaker 2: for a lot of what we still do today, just
Speaker 2: maybe with different tools sometimes.
Speaker 1: Which I guess raises a really interesting question for you
Speaker 1: the listener to consider now, given how the technology landscape
Speaker 1: and obviously the Salesforce platform itself have evolved since twenty fourteen.
Speaker 1: I mean, think about lightning experience, the rise of Flow
Speaker 1: for automation, Heroku Connect for data sinc. Newer mobile SDKs,
Speaker 1: Lightning web components, way more declarative options for integration.
Speaker 2: Now, Yeah, the platform looks quite different in many ways.
Speaker 1: So the question is looking back at these twenty fourteen blueprints,
Speaker 1: what fundamental ideas, what core patterns do you think remain
Speaker 1: absolutely essential for modern salesforce development? And which ones have
Speaker 1: maybe been completely abstracted away or of radically changed shape
Speaker 1: because of new platform features.
Speaker 2: That's a great question. What problems were developer solving back
Speaker 2: then with intricate APEX triggers, visual force pages, complex callouts
Speaker 2: that maybe you'd solve entirely differently, perhaps much more easily,
Speaker 2: using today's two tools like Flow or platform events or
Speaker 2: meal soft or different integration patterns.
Speaker 1: Yeah, where have the tools evolved to solve those same
Speaker 1: underlying business problems in a new way? Something definitely worth
Speaker 1: thinking about.