Salesforce, Developer, A. Set discussed on Software Engineering Daily


Chuck. Welcome to the show. Great. The beer we're talking today about salesforce and building on top of salesforce. So I think it's fair to ask I you know most people think of salesforce as just a big platform for doing your sales and marketing on. On a cloud platform, but it actually is this big ecosystem where people are. Third Party applications and there's lots of developers that work entirely in salesforce just like people would think of wordpress developers tell me a little bit about the salesforce developer ecosystem. What I think wordpress actually a pretty rich analogy there because it's kind of a business application construction tool rate. When I first got into it. I really thought of it as a Sierra as doing thanks to support sales teams, and that's originally originally was doing, but they've really expanded the. Surface area of the platform over the years and it's become a much more general purpose built really think of it. Now, as more like an azure native, you ask where I went to build apps that's a good place to do so. What would be an example that might surprise people because they think of salesforce is you know sales and marketing platform what would be an example of something more abstract or off the beaten path. So a few different interesting projects in the past, all describe a couple of just to give you a sense of what's possible. We did a build for a company that sells used laboratory equipment like big manufacturing equipment. They sell secondhand equipment and we built A. Set. Of APPS for them where there is a mobile piece, a technician would go to a factory being closed down with take of equipment and sort of inventory things. We will track the inventory in salesforce items that could be sort of process and put up for sale, and then we did a mash up with s three to soar all the images. All the pictures are being taken of the Matori, and we would affiliate the images in S. three with the item Meta, data in salesforce. So that was all sort of affiliated set of records. And then we actually did a storefront. Where there's a public website that people can go to to see this inventory and it's searchable filter bubble you can register your intent to purchase something and be contacted. That was all sort of affiliated with this business, but it was writing on sales sort of full stack sales for centric. That's one example. Another example did is there was a project some years ago where It was lead marketplace where this teams wanted real time access to leads You would register your interest on a website or something, and you get a phone call within a few minutes and so. There was a very dynamic nature to it. And we ended up doing sort of building a multi tenant environment on top of a single salesforce work where this company that we were doing the project for would sell access to their system, their engine of sort of lead processing validations all about sort of good quality leads and filtering and evaluating the leads in real time, and so we built a a rules engine that could sort of process these leads that they were selling to their customers and we tied to elastic search, which has phenomenal real time. Filtering and querying abilities and built Essentially, an analytics dashboard using bootstrap where people could build their own analytics like these end customers. The customers of our customer could go into a dashboard and configure little cards with all kinds of interesting metrics that they want. You know this value divided by that value over this period of time, really kind of fairly arbitrary calculations and it would generate a sort of sanitized live query against the elastic search instance off platform that was her distinct sync up with these sales were. So that, we could both collect the data in salesforce and allow them to. Interact with it in a very dynamic way which was really interesting. So those are two examples of some projects that have done. That are maybe not quite the norm. Tell me more about the abstractions that salesforce exposes to the developer for building applications. So, what are the things that really intrigues me and delights me about the platform? I'm very. A little bit of a a walker purist when it comes to software patterns and good design principles, I'm a big fan of Eric Evans and domain driven design and one of the things that are Evans talks about this idea of ubiquitous language that there's a a set of nouns verbs that make sense to the business people and the architects, the developers of A. System and that those sort of natural language items that everyone understands the definition of derive both the way, the business works, and the way the technology works as a really interesting idea and it's important and I think more than most systems have interacted with sales has a really good job of making it possible to design a system where ubiquitous languages in the forefront. What I mean by that is It's such a Meta, data focus platform. You can define a custom objects which are tables and fields and sort of processes and flows and just. Name them and have them do what you want. You can stitch them together and build relationships between things. And because everything is so tied to that meditate just by creating a new custom object, it becomes service in the API, becomes available to you in your declared tools that becomes accessible using sort of compiler time checks from your code. So you get to just sort of create all this abstract conceptual stuff that becomes very accessible to all the tools whether they know Ephron your part. So it gives you the flexibility to really tie the technical work. You do to sort of abstract ideas which I find really interesting. This is probably one of the most successful things that dealt with the platform in my mind from a design perspective. Let's talk a little bit about the security model. So the user security model for building on top of salesforce. What does that look like? So there's every. Access to the system as affiliated with a user record. and He's record doesn't have to be a human being, but there's always a user record tied to all kinds of access. Anton records created touched is done from a user perspective. So you have that and then you also have the idea of an Org right so an Oregon instance is what salesforce calls a single slice of their multi tenant environment. So as a business, you have a single or and all the records in your data set the you interact with belong to your award in actually under the hood is a much larger database with different org coexisting on the same pod. But from your perspective on the access stuff tied to your organ, you've no control over that you can't get outside of your Oregon's very well sort firewall from the other customers. And then within that model, a user can be affiliated with different sets of permission. So there's a sort of a large control, call the profile and a profile is sort of your major what you are like an Admin or marketing team or sales team that sort of thing, and then within profiles you can set all kinds of access rules. It's just sort of a big bucket of big categorization. And then much more gradually, there's this idea that permission set, which is just a collection of things that someone's allowed to. You can give it whatever name you want. You can create as many as you want to sign them to people. and. Those are meant to do sort of enhancements rights also progressive enhancement. So by default, you want people have no access and then you can add onto it. So profile usually gives a minimum basic set of things further enhanced that with permission sets. Every record in salesforce has this idea of an owner. So every record has an owner and the permissions try from that owner. So if I own a record and we worked together and you're my boss, then they permissions can be granted so that all the records I own, my boss also can see or made my boss also. Can. Edit or maybe my team has access to there's actually a really robust set of ways to do the permissions. It can be overwhelming for some people for sure especially when you're first getting started on the Admin side and trying to understand how to model the stuff because it's so flexible but it's really powerful I I. Don't think I've ever run across the situation that couldn't be modeled at all Shanley ways that ended up being a little complicated. So giving sample something a little more complicated is idea of public group, which is just a collection of people righteous a bucket. and. So you can define if you have no sort of natural environment for user time like the hierarchy of the or something but there is some way that people were affiliated maybe cross functional teams across different departments or whatever You can just put them in a public group sort of a a last resort, just a way to put people together and you can affiliate permission to the public. So you can say this, the blue team has these sets of promotions and this is these are criteria. For being on on the blue team, but often you need some sort of programmatic level up definition. So you can really get in the weeds with the permission system in two ways one. The public groups are actually sort of meditated. You can manipulate using code so you can assign a person to a group, remove a person from a group from code..

Coming up next