Force.com Development Blueprints

Okay, let's unpack this one. Yeah, today we're diving into something pretty interesting. It's excerpts from a book Force dot Com Development Blueprints from back in twenty fourteen.

Right, twenty fourteen, so like a decade ago now roughly exactly.

It's kind of like hitting the way of back machine, you know, seeing how experienced developers were building some pretty sophisticated applications on the Force dot Com platform back then. So our goal, our mission for this deep dive, it's really to pull out those core blueprints, those patterns.

Yeah, the essential ideas, the how to from that era.

And figure out, okay, why did this stuff matter back then? And importantly for you listening, what enduring value is there? What can we still learn from it today? Does it still hold up?

That's right? And we're grounding this whole discussion in this packbook by Steven Moss. This guy, Stephen, he was a Force dot Com developer, certified admin to with like over twenty years in it.

Wow, twenty years even back then, Yeah.

Going way back. He programmed on a Commodore sixty four and his background was super diverse. CRM sure, but also gis manufacturing even early mobile dev the book mentions he still had a palm pilot.

Sleigh chuckle, a palm pilot. Yeah, that really paints a picture of the tech landscape, then, doesn't it.

It absolutely does. And importantly, this wasn't just you know, one guy's opinion. The book had several experience reviewers too, people with deep backgrounds in Salesforce, architecture, consulting various IT fields.

Okay, so it's grounded in real world practice, not just.

Theory, exactly practical hands on experience from that time. And yeah, the specific versions of sales coorse features they're from twenty fourteen. But the underlying approach, how they use the platform's building blocks, objects, code, integration points, that's what's really insightful, I think.

Right, So let's dive into that first blueprint the book lays out. It tackles a pretty fundamental challenge, how do you build those external facing websites or maybe communities that are tightly integrated with through Force dot com data.

Right, And this blueprint it really leverages what were key features for this back then, communities Incite dot com. The main idea was using these native platform tools, you could expose you know, select Force dot com data and processes to people outside.

Your org without needing a whole separate database or tons of complex infrastructure.

Right exactly. It simplified things quite a bit.

And the book walks through a specific example setting up this Force Volunteers community. So sorts of the basics the setup. Get to enable communities in your org the first that, and create the specific community instance itself to find the Force dot Com objects they'll interact with, like the use of volunteer event custom object.

Example, right, the data structure underneath, and.

Then crucial details like setting up specific user profiles they mentioned a volunteer community user profile and getting those permissions just right often read only access to things like accounts, contacts, and those volunteer events.

Yeah, that's set up. Part is critical. It defines the data model and exactly who gets to see what. But the really interesting bit, I think is how they actually built the look and feel of the public site. Okay, the blueprint uses site dot com Studio, which was this visual design tool. Think of it like well, kind of a precursor to modern drag and drop.

Builders made a visual page building.

Yeah, letting you assemble pages using components things like header and footer widgets. You could manage assets like images, logos right there in Salesforce, and you could customize the branding visually, down to setting color schemes with like HDML color codes.

Right. But it wasn't just about making static pages look nice. The real power came from embedding live data. Yeah, totally.

The blueprint shows how you could like drag a data table component onto an events page, point it at that volunteer event custom object you set.

Up, and boom, there's your list of events.

Exactly, pulled straight from your Salesforce data live. And you could configure filtering as ordering right thereinthsite dot com editor like show events sorted by start day, ascending order that kind of thing. Ic and security making sure only the right people see certain.

Pages, yeah, that was handled too. You could secure pages with a simple setting. The book mentions a padlock icon appearing so certain content only visible to logged in community members. You could even add personalized elements like maybe a chatterfeed showing stuff relevant to the logged in volunteer on their profile page.

So the big takeaway from this first blueprint it's really that even a decade ago, the platform offered these pretty robust built in tools, tools that let you go from just an internal data model to a full on, branded, data driven external site with user management security.

Yeah, and it's significantly lowered the barrier to entry, didn't it compared to building all that from scratch with traditional webstacks. Abstracted away a lot of the back end headache.

That's a great point. Okay, shifting gears now completely different, direc The sources also lay out a blueprint for an e commerce solution. But this isn't just building order forms inside Salesforce.

No, this is different. This is about using Force dot com as the back end system for an external online store.

And they use a fun example, a fictional company selling like high performance racing car engines.

Nice.

The approach starts, you know where it usually does, defining the data model within Force dot com. So custom objects like order orderline item maybe for the engine types, and order line for these specific items in a.

Particular order, right the core data structure.

And the blueprint gets pretty specific about configuring the fields, setting up the right field types, number, picklist, currency, and defining the relationships like lookups or master detail between these objects.

Now, why is that level of detail on field types and names so critical in this specific blueprint.

Ah, because the crucial piece here isn't just the Force dot Com side, it's the integration. This whole solution depends heavily on an external e commerce website talking to Salesforce, and for that connection that API communication to work smoothly. The data structure, the field types, even the exact field names Inforce dot Com. They need to align precisely with what the external application expects when it's sending or asking for data. Any mismatch causes problems.

Ah, got it, That makes perfect sense. So this external site, where does it live? What's powering it?

This is where Heroku comes into the picture. Remember, Salesforce had acquired Heroku a few years before twenty fourteen. So the book highlights Heroku as the platform for hosting this external store, okay, and it emphasizes Heroku's polyglot nature, you know, its ability to run apps written in different languages like Ruby on Rails, Java, no JS, Python gives developers flexidadity.

So the blueprint details setting up that dev environment like installing node Rubyon, Rails.

Yep exactly, mentions minimum versions, installing get and crucially, it walks through configuring a Force dot Com remote act access application in.

That remote access app. That's the key for the secure connection, the handshake between Heroku and Forest dot Com.

Precisely, that's how the external Heroku app gets the owooth credentials. It needs the consumer key and secret that lets it connect securely to the Force dot Com API and actually access the data, create records, et cetera.

Okay, and the example uses Ruby on Rails for the external site.

Yeah, the example build is in Rails and it uses a library called the Force dot rb rubygem. The book describes it as a nice wrapper around the Force dot Com rest API. Basically, it simplifies making those API calls from Ruby to do things like create order records in Salesforce or look up product info stored there.

So let's trace the flow. A customer goes to the external site on Heroku. They place an order for a racing engine. That Rails app uses the Force dot RBGM and the off credentials to talk to the Force dot Com rest.

API and creates the order order line item order line records inside Salesforce.

Okay, so the order data lands Inforce dot Com. What happens then? Who handles it?

Right? So? Now Force dot Com shifts into being the fulfillment and management system. The blueprint includes building an internal fulfillment application within Force dot com itself using APEX controllers and visual Force pages.

Ah, so internal users log into Salesforce exactly.

They log into this custom fulfillment app. They can search for new orders that came in from the external site, manage the order status, handle the shipping, the whole fulfillment process.

Gotcha. So the core insight here pretty powerful. This blueprint really shows Force dot com not just as a place to build apps, but as a kind of robust, secure data hub and process engine for applications build anywhere else on totally different textacts connected via APIs.

Yeah, and that pattern using Salesforce as a back end service that's arguably even more relevant today, isn't it in our whole micro services API first world?

Absolutely. It really demonstrates the platform's flexibility beyond just its own native UI. Okay, let's pivot again. Let's go to a more class CRM scenario. The sources give a detailed blueprint for a student admission system for fictional Force University. This sounds like building a comprehensive, process driven application entirely within Force dot Com. Yeah.

This is a great example of building out complex business logic using mostly native platform capabilities, and it starts as you'd expect with a solid data model. You need to track everything related.

To admissions, so custom objects.

Right, custom objects like course applicant and course application, and they get into the field specifics again using dependent picklists, maybe for course details. Marking certain applicant fields is required given name, surname, date of birth, address.

All that core info, and probably a status field for the application itself.

Definitely a picklist for application status on the course application object with values tracking the whole life cycle new under assessment, closed admit applicant, closed reject applicant, things like that.

Makes sense now beyond just storing the data the system, like admission, it needs really careful management of who can see what and how these applications actually move through the process.

Absolutely, access control and workflow automation are central here. The blueprint outlines setting up different profiles, maybe one for course administration, one for the admissions office staff, one for selection officers who make the decisions, and also a role hierarchy that mirrors the university structure, you know, president at the top down through dean's managers, officers.

And that combination of profiles and roles lets you control permissions very.

Granularly, exactly granular control over object access, field level security. Making sure users only see and edit the data that's relevant to their specific role in the whole admissions process, keeps things secure and focused.

Okay, that covers access. What about the process automation? How does an application automatically move from say new to under assessment and get assigned to the right team or person.

Ah, this is where they combine configuration and code quite cleverly. I thought the blueprint uses cues standard Salesforce cues OKA. Maybe one queue for the business faculty admissions team, one for the science faculty, perhaps an exception queue for applications that need special handling. These cues act as holding bins for the applications.

And how does the system know which queue to send an application to based on the course they applied for?

Precisely? And they even suggest using custom settings remember those to create a mapping. You'd map specific faculties or courses to their corresponding quids in the custom settings.

Oh that's smart. So the routing destination becomes configurable without needing to change code later.

Exactly makes it more maintainable.

So you set up the queues, you set up the mapping and custom settings, but how does the system automatically perform the routing when a new application comes in? What triggers that?

That piece is handled by an APEX trigger. The blueprint implements the core routing logic in a before insert trigger on the course application object.

Before insert, so it fires before the new application record is actually.

Saved yep, before it hits database. The trigger logic looks at the course the applicant applied for it, queries those custom settings to find the correct faculty QID based on the mapping, and.

Then it sets the owner reed field on the new course application record to that qid exactly.

So the moment the record is saved, it's already assigned to the correct queue, ready for that team to pick it up.

Wow, that's a really neat pattern. You're using clicksnot code for the queues and the configurable mapping, but then a targeted piece of APEX code for the dynamic routing logic based on that configuration. That's a great aha moment showing how those different platform tools work together. For pre sophisticated automation.

It really is, and they didn't stop just at routing. The blueprint also included a user experience enhancement, a decision entry.

Publisher action would you like a quick action today?

Yeah, basically a quick action. This was placed right on the course application record page, probably in the chatter feed. It let a selection officer quickly pop open a little form, enter their disis, admit, reject, add some notes, update the status field.

All directly from the context of that record's.

Feed exactly, and it would automatically generate a chatter posting, decision entered, admit, or whatever super streamline for that common task, and it kept everyone collaborating on that record informed right there in the feed.

Nice. So this blueprint it really showcases building these complex human centric business processes and to end on the platform using that mix of declarative tools and code where needed.

Definitely, and they mentioned potential next steps too, like adding an approvals process or workflows to automatically email applicants their results. You can see how you'd layer more automation on top.

Okay, shifting focus again. Reporting can't run a business or university without good reporting. The source even quotes that classic line if you cannot measure it, you cannot improve it.

A fundamental truth.

But this blueprint it's not really about standard salesforce reports and dashboards, is it. It's about building custom reporting capabilities.

Exactly when the standard out of the box reporting tools maybe don't give you the specific calculations, the specific layout, or maybe the performance you need.

And the example they use is an executive information system an EIS dashboard for a fictional force majure insurance brokers. Sound serious?

Yeah, The goal was to provide those specific aggregated key performance indicators KPIs that executives need at a glance, things that might require complex calculations or pulling data together in ways standard reports struggle with.

Okay, So how do they approach building that custom reporting engine on force dot com? Where does it start?

Well, like the others, it starts with the data model required for the report itself. They outline custom objects like EIS policy to hold the core insurance policy data, and another object called EIS dashboard.

An EIS dashboard object, what's that for?

The book suggests that in a real production environment you might use something like analytical snapshots scheduled jobs that capture aggregated overtime to populate this EIS dashboard object, so it holds the historical trend data needed for the dashboard.

Ah okay, a way to snapshot results for performance and trending exactly.

And then they detail adding the specific fields needed on the EIS policy object, things like policy date, policy type like auto home life, policy amount, whether it's a renewal, the renewal date, all the raw data points the customer report wanted to crunch.

So you've get the data structure defined. Where does the custom logic the calculation engine actually live.

That's handled primarily by an APEX controller paired with a visual force page for the display. The APEX controller is really the brains of this operation.

Okay.

It defines properties to hold the filtering criteria the user selects on the page like a start an end date range, maybe filter by policy type. And importantly it has properties to store the final calculated KPI values that will be displayed.

And does the controller handle getting the filter options too, like the lurk of policy type.

Yeah, and there's a neat detail mention. The controllers constructor can dynamically populate the options for the policy type. PICKLST filter on the page It does this by introspecting the schema of the es policic object using apex code schema dot pickless entry, so if you add a new policy type later, it automatically shows up as a filter option.

Oh that's nice. Dynamic picklists based on schema are always good for maintainability avoids hard coding. So what kind of logic is running inside that controller? To actually calculate the KPIs.

The core methods execute aggregate socle queries. This is where you leverage the power of the Force dot com database engine directly from apex.

So using sum count, group by backay exactly.

They use socle functions like some policy amount or counted to aggregate data from that EIS policy object. They apply filters based on the user's selected date range and policy type using wear clauses. Sometimes they group by policy type or date periods.

And the apex code then takes those raw aggregated results.

From SOCO and performs the final calculations to derive the specific KPIs. The business needs things like you know, total renewals amount, renewal success rate percentage, which might involve comparing counts number of new policies. One maybe policy growth percentage compared to a previous period.

Got it. So SOCLE does the heavy lifting on aggregation, APIX does the final math in business logic, and the Visual Force page is the presentation layer showing this all to the executive YEP.

The Visual Force page eis dashboard page dot page provides the user interface. It's got the input fields for selecting the date, range and policy type filter, a command button that tells the APEX controller to run the calculations.

And then displays the results.

Right. It displays those calculated KPI values using components like apex dot output text, and they mention using formatting masks within the Visual Force to display currency or percentages correctly like hashtag date zero zero zero zero.

Makes sense for a clean look.

And the blueprint also mentions including visual Force chart components APAX dot chart to actually visualize some of this data, not just show numbers.

And they point out a couple of technical details using read only true on the Visual Force page and setting doc type HTML five point zero. Why call those out?

Well, read only true was and still is a significant performance optimization for visual force pages that don't need to maintain component view state between server requests. If your page is just displaying data calculated by the controller. Using read only true can make it load noticeably faster because the server doesn't have to serialize and de serialize that view state.

Okay, good performance tip, and the doc type.

Setting doc type HTML five point zero just ensures the page renders using modern HTML five standards, which was becoming the standard around twenty fourteen. Helps with browser compatibility and using newer HTML features if needed.

So this blueprint is a great example of how when standard reports hit their limits, developers could roll up their sleeves and use APEX and Visual Force to build highly customized, potentially complex, data heavy dashboards directly on the platform, leveraging its database power and programmatic control.

Absolutely, it really highlights that flexibility for bespoke reporting needs.

Okay, now let's talk mobile. The mobile revolution was definitely in full swing by twenty fourteen. Salesforce one had launched, so the sources dive into building mobile applications using the Salesforce Mobile SDK.

Yeah, they had to address mobile, and they start by outlining the main approaches you could take back then three main paths. One was building pure HTML five web apps designed to run well in a mobile browser. Or within the Salesforce one container. Second was hybrid apps, typically using a patche cordova, which lets you wrap your web code HTML, CSS, JavaScript inside a native app shell, giving you access to some device features.

Right like a web app pretending to be a native app.

Kind of yeah. And the third path was fully native apps using the specific Salesforce mobile SDKs for iOS and Android to build apps using objective C, Swift or Java.

In which path does this blueprint focus on?

This specific blueprint digs primarily into the HTML five approach, which was pretty popular because it let web developers leverage their existing skills HTML, JavaScript's CSS to build mobile experiences connected to Salesforce relatively quickly.

So htail five mobile apps. What kind of web technologies are they combining here? In this blueprint?

The core idea was building these things called single page applications or spas, where most of the UI and logic runs in the browser using JavaScript. The blueprint specifically mentions using Angular JS, which was a really popular JavaScript framework back then maintained by Google well suited for this kind of model view controller NBC architecture in the front end.

Okay, angular JS? What else?

They also leverage Twitter Bootstrap for the UI components and making the layout responsive so it looked okay on phones and tablets without writing tons of custom CSS.

Bootstraps still around very useful.

And jQuery, which was pretty much ubiquitous back then and also a dependency for some of the Salesforce Mobile SDK's JavaScript libraries.

So you've got Angular Bootstrap, jQuery running as an HTML five app. How does it actually connect to Salesforce data and handle authentication?

That's where the Salesforce Mobile SDK libraries come in. The blueprint details setting up the application files, including downloading a specific Salesforce Angular JS mobile pack they provided back then, okay.

A specific pack for Angular integration.

Yeah, and key parts involved initializing the Angular JS app correctly and wiring it up with the SDK's JavaScript libraries, things like Angularforce, dot JS, Force Attk dot Mobile SDKJS. These libraries handled.

The hard parts looked like authentication exactly.

The blueprint explains the authentication flow, which relied on Angular JS controllers managing the Salesforce OS process, you know, initiating the log in, handling the callback from Salesforce with the access token, storing token securely, refreshing them when needed and redirecting users once they were logged in. The SDK libraries provided functions to help with all that.

Okay, so the users authenticated, the framework is set up up, how do you actually get the business data, like say, catching opportunity records to display in the mobile app.

This is where they show a common pattern from the Angular JS world, creating something called an opportunity factory a factory. In Angular terms, a factory was basically a reusable service, a chunk of code designed to interact with the Salesforce data via the SDK's helper functions. So this opportunity factory would have methods like get less opportunities, get opportunity details, opportunity.

At standard CRD like operations.

Pretty much, but here's where it gets especially interesting. The factory also had a method like get opportunities nearby latitude, longitude radius.

Wait, hang on, the mobile app can query Salesforce for records based on geographic location. How does that work? That sounds pretty advanced for twenty fourteen.

It was pretty cool. It leveraged a specific soacole query capability called geolocation and distance, but it required some significant setup on the back end and Salesforce.

First, okay, what kind of setup.

Well, first, to even store location data, the blue print shows adding a new field to the account object in salesforce, a field of the geolocation data type, which stores latitude and longitude coordinates.

Right, you need somewhere to put the coordinates. Yeah, but how do those coordinates get into that field? Accounts usually just have billing addresses.

Ah, good question. They don't magically appear. This required more work. It required code APEX again. Yep, the blueprint includes an APEX utility class and crucially, an APEX trigger. This trigger fired whenever an account record was inserted or updated.

And what does the trigger do?

It automatically made an HTTP call out from APEX to an external service, specifically the Google geocoding API. It sent the account's billing address, street, city, state ZIP to Google.

And Google's API sent back the latitude and longitude for that address exactly.

The APEX trigger then took those coordinates returned by Google and saved them into that new geolocation field on the account record.

Wow. Okay, hold on, so they're using an APEX You're firing on save to make a real time web service call out to an external api. Google just to enrich the Salesforce data with coordinates before the mobile app even tries to query base on location. That's quite a bit of back end automation just to enable that one mobile feature.

It absolutely is, and it wasn't trivial to set up. It required configuring a remote site setting in Salesforce to allow APEX to make calouts to the Google Api endpoint. And you need to get a Google API key which might have had usage limits or.

Costs, right external dependencies. So, once all that back end work is done, the geofield exists, the trigger is firing, accounts are getting geocoded, and how does the mobile app use it?

Okay, So now the mobile app, using an Angular JS controller to call it. An opmap controller in the example could first get the user's current location from the device's GPS.

Using browser geolocation APIs or Cordova plugins probably yeah.

Then, armed with the user's current lat long, that controller could call the get opportunities nearby method in the op Portunity factory.

And that factory method would use the Salesforce Mobile.

SDK to construct a specific soacle query using the distance function, something like select name from opportunity where distance account location lacktuon uger lab user lawn my five searching for opportunities linked to accounts whose location field is within say five miles of the user's current.

Location, and Salesforce handles that spatial query on the back end using the index geolocation field.

Then the results come back to the mobile app, and the outmap controller could take that list of nearby opportunities and display them as markers on an embedded Google Map within the HTML five app.

That is, that's a really impressive end to end scenario. It perfectly demonstrates building a truly context a wear location based mobile experience, but it involves combining front end web tech, Angular bootstrap maps, the mobile SDK for data access, and off significant back end APEX automation for data enrichment and integration with external APIs like Google goocode shows all the layers you might need.

It really does. It brings home that idea of Force dot com as a platform you build on leveraging all its pieces, not just in the standard UI, and the blueprint also briefly touches on setting up the native Android SDK using the forstraid command, hinting at that alternative path too.

Fascinating stuff. Okay, one final blueprint. This one takes the idea of external integration even further. It's about connecting a Force dot Com application to another major cloud platform, specifically Microsoft Windows Azure.

Yeah, this one pushes the integration boundary, and the particular Azure service they explore is Azure Notification Hubs.

Notification HUBS so for sending push notifications to mobile.

Apps, exactly as your Notification Hubs was and is Microsoft service designed to simplify sending mobile push notifications reliably across all the different platforms iOS, APNS, Android, GCMFCM, Windows devices, all through a single unified rest API.

As it abstracts away the complexity of talking directly to apples and Google's push.

Services precisely that was the big value prop handles, load balancing, queuing, device registration management, all that complexity for you.

So this blueprint is about using Force dot Com to initiate sending push notifications out to mobile apps, potentially apps built using the Salesforce Native SDK, but leveraging Azure as the delivery mechanism.

You got it. And this blueprint actually assumes you're working with a native Android application, one built using the Salesforce Android Native Mobile SDK, unlike the previous Ashmel five example.

Okay, so native Android this time. Yeah.

The setup section details getting the Android Developer Tools ADT bundle, setting up an Android Virtual Device add for testing, and installing the Salesforce Android Native Mobile SDK using that four stroid command line tool we mentioned, and of course configuring the Salesforce Connected app with the right otooth settings for a native mobile app.

Flow makes sense. What about the setup needed on the Azure side.

On the Azure side, you first need to interact with Google Cloud Messaging GCM which is now Fire Based Cloud Messaging FCM, to get an API project number and an API key. Azure needs these credentials to be allowed to send notifications via Google's infrastructure to Android devices.

Ok to yeah, the Google keys.

Then you can figure the Azure notification hub itself within the Azure portal. You create a name space, then create a hub within that name space, and critically, you link that hub to your GCMAPI key so Azure knows how to talk to Google for your app. You also need to grab your Azure Service Bus credentials, specifically an endpoint URL and an access key.

All right, So quite a bit of setup on both Salesforce Android and Azure Google fronts. Now you have the native Android app potentially ready to receive notifications and Azure is configure to send them via GCM. Howdes Force dot Com actually trigger Azure to send a message? That's the core in creation right.

That is the core, and it happens via apex code making callouts from Force dot Com directly to the Azure notification hubs rest API.

Okay, Apex again talking do external RESTSPI exactly.

The blueprint details building a set of apex classes that effectively act as a rapper or an interface to the Azure and Notification hubs API. These classes contain key methods to like what first a method to get an Azure access token Back in twenty fourteen, Azure notification hubs often use something called OWR app for authentication, which was a

Credential, and that calla would need a remote site setting in Salesforce right to allow Apex to call the Azure.

Endpoint absolutely required a remote site setting. The response gave you a short lived access token. Second, maybe a method to query Azure to get a list of existing device registrations associated with your notification hub. See which mobile users have actually registered their devices with Azure.

Okay, so you can see who's listening yep.

And third, the most crucial step, the method to actually send a message through the notification hub. This involved making another http PST request from Apex, this time to the notification hub's main rest API endpoint, which needed another remote site setting for the hub's namespace RL.

And what goes in that post request.

You'd include the Azure access token you obtained earlier. In the authorization header, you'd specified target tags. Azure notification hubs uses tags for targeting. A common pattern was to have the mobile app register itself with Azure using the Salesforce user idea as a tag. So from Apex you could target the message to a specific Salesforce user ID tag. And of course you include the actual message payload you want to send in the request body.

Wow. Okay, so Apex is potentially making one cal out to get an Azure token. Maybe another to query registrations, and then a third cal out to actually send the notification payload to a specific tag via the Azure rest API. This sounds pretty intricate, a multi step cloud to cloud integration.

It is definitely intricate, but it highlights the platform's capability back then to perform these complex server to server integrations directly interacting with other major cloud providers. APIs right from within apex code.

Okay, so Apex handles the back end communication with Asher. How does a regular Salesforce user initiate this? They don't write apex right.

So the final piece of the blueprint is building a simple user interface within Force dot com a visual Force page and a supporting.

Apex controller, and what does his page let them do?

This UI would allow a Salesforce user, maybe a support agent or a manager, to say, select which registered mobile user they want to send a message to. The picklist of users could be populated by querying Salesforce user records whose user IDs match the registration tags retrieved from Azure. Using that second Apex method we talked about clever, so you only show users who actually have the app registered exactly.

And then there'd be a text box to type the message content. When the Salesforce user clicks a send message button on the visual Force page.

The controller calls that third APEX method, which makes the call out to the Adjure Notification Hub rest API, passing the selected user ID tag and the message text precisely.

Azure then takes over, finds the device registered with that tag and sends the push notification via Google's GCMFCM infrastructure to the user's Android device.

That's a very sophisticated blueprint. It really demonstrates a complex cloud to cloud integration pattern. Plus the cloud to mobile piece, all orchestrated and initiated from within Force dot Com shows its potential as a central command center for these kinds of connected applications.

Absolutely, it ties a lot of different pieces together, native mobile SDK, apex colouts, external cloud services, visual Force UI. So let's try and wrap this deep dive up. We've looked at these six predistinct blueprints from this twenty fourteen book building communities, e commerce, back ends, internal CRM processes, custom reporting, mobile apps, cloud integrations. What's the big picture takeaway when you look back at all of them.

Well, the clear picture that emerges, I think is that Force dot Com even a decade ago, was being presented and used as a really highly capable, very adaptable platform. It wasn't just for building standard CRM screens. It could do much more.

Yeah, you see it being used for external engagement with those communities and site dot com tools acting. Is that robust back end, data store and API layer for totally external systems like that e commerce site running on heroco.

Right, the headless pattern almost.

Powering complex internal business processes with automation like the student admissions example. Yet workflow in logic, delivering custom beta heavy reporting dashboards when the standard ones weren't.

Enough, going beyond standard reports.

Building quite sophisticated mobile experiences using the SDK, including location.

Awareness, leveraging device capabilities, and even acting as the orchestrator for integrations with other major cloud services like as your notification humps. Yeah, connecting the clouds across all these different scenarios. You see the same or platform elements being used in different ways.

You really do you see custom objects providing that flexible data layer underneath everything. Yeah, you see profiles, permissions rolls handling the security aspect. You see APEX and visual force popping up for custom logic, custom UI and especially for those crucial integrations, and maybe most importantly, you see the APIs and the SDKs acting as the doorways, the way to connect Force dot Com outwards to other systems or to build entirely new experiences like mobile apps on top of it.

Exactly the platform's strength, even back then, seems to be rooted in that rapid application development capability, handling the infrastructure burden for you, while still providing those essential hooks, those integration points you needed to extend it and connect it to the wider world.

It's really fascinating to see how these patterns, these blueprints for integration, for process automation, for leveraging mobile, for connecting clouds, how they're being defined and implemented using the specific tools and features available on the PLATF in twenty fourteen.

It really is you can see the foundation being laid for a lot of what we still do today, just maybe with different tools sometimes.

Which I guess raises a really interesting question for you the listener to consider now, given how the technology landscape and obviously the Salesforce platform itself have evolved since twenty fourteen. I mean, think about lightning experience, the rise of Flow for automation, Heroku Connect for data sinc. Newer mobile SDKs, Lightning web components, way more declarative options for integration.

Now, Yeah, the platform looks quite different in many ways.

So the question is looking back at these twenty fourteen blueprints, what fundamental ideas, what core patterns do you think remain absolutely essential for modern salesforce development? And which ones have maybe been completely abstracted away or of radically changed shape because of new platform features.

That's a great question. What problems were developer solving back then with intricate APEX triggers, visual force pages, complex callouts that maybe you'd solve entirely differently, perhaps much more easily, using today's two tools like Flow or platform events or meal soft or different integration patterns.

Yeah, where have the tools evolved to solve those same underlying business problems in a new way? Something definitely worth thinking about.