Piyush (00:00):
We have been in business for more than seven years now. We look after end-to-end implementation for customers worldwide - whether it's a Salesforce implementation or building a hybrid system with different systems inside of Salesforce. Apart from Salesforce, we deal in Zoho CRM as well, but that's not a big part of our business model.
Leonard (00:32):
Bill, why don't you tell us a little bit about you in Minnesota?
Bill (00:36):
Ah, thank you. So I'm a veteran software designer and engineer I've built three or four dozen enterprise apps over the years. And I got started with Salesforce back in 2005 and wrote the first third party Salesforce app that I'm aware of - Dream Team, which you may remember. We wrote a couple of others (like Snapshot), and to make a long story short, we now have a new company called Metazoa. We're focused on the Snapshot Apple application, which is an org management application that makes it easy for admins to manage their orders, take care of security compliance, move metadata from one org to another, and move data. I'm a keen observer of the Salesforce ecosystem, and I'm ready to talk about some of the new things that are available here for the summer release.
Leonard (01:36):
I talked with both Bill and Piyush before the webinar, and both of you guys picked out a couple of things that you want to talk about. Bill, I think we'll let you kick it off with the changes that were in profiles and permissions. Some of those are just tweaks that came out in the Spring of 20 release, and I don't know if everybody's been up on those. Maybe you could talk a little bit about Spring 20 and Summer 20 all in one?
Bill (02:12):
Sure, sure. So, Summer 20 has the GA release of permission set groups. In spring, they had the beta release - but now it's available everywhere. Permission set groups are a great addition to the platform and for anyone dealing with Salesforce. If you go back to the beginning - 2005, 2005 - the only thing you had was profiles. Every user had a profile, and the profiles were where permissions got stored. Over time, they kept adding more and more permissions to profiles, until they started with the whole object permissions and Beal permissions and Apex permissions, and maybe ten other things, from record types to page layouts.
Bill (03:09):
What happened is the profile became this monstrous object that had all of this information in it, especially field permissions - because if you multiply the number of fields from the number of profiles, times the size of those things, you could get profiles that were many hundreds of megabytes in size. It became awkward.
Bill (03:30):
The problem was that if a user goes to their admin and says, "I need this new permission," the admin really had one of two choices - they could either clone the profile and add the permission to it, or they could just add the permission to their profile and forget about it. Well, if you do option one, you create another profile, and if you do option two, then you've just added more of an attack space of security leak on your entire Salesforce. So, then they came out with permission sets - the exact opposite of an object. They were sparse. You could just put the individual profiles that you wanted in this little permission set. That was good, and it fixed the problem of the special cases. However, now you had this kind of monolithic profile, and this add-in permission set. So, permission set groups - which are finally GA now on this new release - fill in that gap. We have the baby bear and the papa bear - this is the mama bear. A permission set group is really simple. You can give it a name, and it can hold any number of mission sets, and then you can assign the group. Now, a user can get a profile, a permission set group, or a permission set. I think it's really important because you really want your permission architecture to be understandable to a security administrator or an admin.
Bill (05:43):
It should be human-readable. It should have clarity. We should have context, and it should have meaning. Now you can give the profile as a base. Let's consider a marketing user. Everyone in marketing should have the same profile. Now, you don't need to give everyone in marketing their own profile. The marketing profile should have the same base permissions that make sense for anybody in marketing. Then, if someone needs an additional capability, you give that capability a good name. Say you've got someone that needs access to the campaign system. You make a permission set group and fill it with the right permission sets, and then everyone who needs that permission gets assigned to that group. If your marketing user needs access to Einstein or something similar, make that a permission set. If you do it that way, you'll be able to look at all the permissions in the org and see by inspection what they do. Essentially, you've taken all that complexity out of the profile object and distributed it into an architecture that gives it meaning, and is way better. This is new for Summer 20.
Leonard (07:07):
That's huge. One of my customers had exactly that issue. They have these nice profiles, except for "Oh, this person needs these five other things - can you clone them?" Can a user have many permission set groups assigned to them, or is it just one-to-one?
Bill (07:29):
That's an interesting point you're bringing up. So, the way that a user gets a permission set, or the way that a user gets a permission set group, or the way that a permission set group gets a permission set are junction objects. A junction object is a custom object. It's got two pointers to the user or the permission set or the permission to that group. So one of the things that have happened is that we've moved all this complexity out of profiles, but now there's a web of assignments between users and permission sets and permission set groups that have some new complexity. If you're trying to do all those things through the setup menu with a big org, that could be an issue. So that's one of the things that our Snapshot product tackles, making that much easier to administer. One really helpful statistic is what's your user-to-profile ratio or profile-to-user ratio. If it's getting towards one profile for every user, that's a really bad sign. We've seen customers with 600 or 700 profiles - that's not good.
Leonard (08:56):
Piyush, I think one of the biggest things that came out was some enhancement to flows. Can you tell us a little bit about your research on that?
Piyush (09:21):
Absolutely. Flows is coming out to give more ability to the end-user or to developers to customize and automate things more. Since the inception of flows a couple of years back, things are getting better and better every day. As a developer or a consultant, the real challenge is having to choose between a flow or writing a piece of code that could be a trigger or batch class or something like that. You don't have to think twice whether to go with the piece of code that's a trigger or a batch class or go with the flow. With this release, what users get is like the writing of flow before the data gets committed. For example, if you write a trigger, it will give you the ability to write a flow before the data commits to the database. That way, you can validate a couple of checks or fill in a couple of empty fields. For instance, recently, we were in a phase looking at creating a trigger before a contract gets saved as a record. The user wanted to save each contract with an end date of six months after saving. Before, we could think about "let's write a trigger to do that." We actually have the flow with us now. So, we created that flow, and it was much easier to do it. Flows are now enhancing the debug facility in it, so you can actually debug and put your debuts in it. It's moving more towards what you could achieve in our trigger. The flows are moving towards that direction.
Leonard (11:30):
Basically, at some point - where Salesforce is going - is that you won't have to write Apex to do a lot of the really common things that got done with triggers a year or two prior.
Piyush (11:48):
It's moving towards more clicks and less code.
Leonard (11:55):
Bill, work.com. Is there such a thing? It's in a beta release in this release. What have you done? You did a little research on that.
Bill (12:08):
We've been talking to the team over there, and there are some very interesting things about it. I'd say it's one of the biggest parts of the new release. I'm not sure it's a managed package, so I'm not really sure it's officially part of Summer 20. Work.com is all about reopening your company in the current COVID-19 crisis, and it provides a command center that helps you see your employees in your facilities and how that stuff works together. So, if you think about Salesforce, you've got users - those are the people with licenses - and you've got partners, and you've got contacts. Objects are new. Now you've got custom objects, and one of them is "employee."
Bill (13:14):
An employee fills the gap between a user and a contact. Now you can think about all of the people in the company that don't necessarily have a Salesforce license because maybe they're not on the sales team. How can those people give you wellness information on a mobile app to tell you how they're doing? How can you organize the shift of workers - maybe you want social distancing in your building? How can you have half the workers come in one time, for half the week, and the other half for the other half of the week? How are you getting the information from your workers about their status? Are they at high risk? Are they recovered? Are they suffering symptoms?
Bill (14:12):
You can get all that information, collate it, and see it across your different facilities. From there, you can organize it and make it work. I think that's critical stuff. If you look at what they've done, and if you look at some of the custom objects, and look at some of the custom objects available - kind of looking under the hood at what Salesforce is thinking about in the future - they've got also got a crisis object for war, pandemic, or natural disaster. I hope we don't use that object much - one's enough - but they're obviously thinking about this in terms of disruption and how employees deal with that problem. I think they're wise to do so. Another part of work.com is contact tracing. That's there for sales to large municipalities that are trying to do contact tracing. I'm not sure that it would be useful to people running individual companies, but it might be. So it's a resource available to employees, along with other wellness resources. So, work.com is really interesting, and it's going to be here soon.
Leonard (15:44):
Two interesting things about Work.com for me. One is the integration of Tableau and MuleSoft into a baseline Salesforce product. That's the first time I've seen them bundle everything together like that as one offering. Tableau is offering basically a dashboard of where COVID is going, which just gleans for public sources information about COVID. The MuleSoft component just pulls data from your HR system to populate that employee object, as I understand it. So, they're saying right at the start that they're a sort of a sidecar system, and we're handling this little piece.
Leonard (16:44):
For our X-Force conference a few months ago, we had Matt Getz from Silver Line CRM. They're an implementation partner for Salesforce for healthcare. They did some things with Salesforce too. It's a case where Salesforce isn't the core product that the enterprise is using to run the business - a hospital has these e-record systems, but those systems are so complex and so hard to change that they can't be part of the COVID response. Salesforce comes in and picks off this little piece and makes that part of the COVID response. That's kind of the first time I've seen that happen with Salesforce. Kind of an exciting direction.
Bill (17:36):
It's so agile, isn't it? Something like this happens, and they can really jump on it.
Leonard (17:45):
Obviously, we're a company that does ETL for Salesforce. It's agile, but it's always kind of an adjunct platform - but it's so agile that people want to turn it into their single source of truth for so many different things. It's kind of an interesting development in the platform. Speaking of things that aren't Sales Cloud, Piyush, you have a pretty good-sized practice and service cloud, and some service cloud upgrades are coming in Summer 20.
Piyush (18:24):
One of the interesting upgrades coming up relates somewhat to what Einstein is doing in Salesforce. So, the Einstein engine is going to help out how people or support staff respond to a ticket if they are in a live chat or conversation with somebody. This is something we already see in Gmail. We see a predictive text when you type in the email. This is now coming in Salesforce support. So, when you do a chat or reply to a case, you'll see predictive test. This comes from the Einstein engine developed by Salesforce. It's actually quite interesting seeing that the world is moving towards predictive text and AI, and what Salesforce is doing.
Piyush (19:21):
This is actually quite interesting seeing that the world is moving towards a predictive text and AI and what Salesforce is doing with Einstein.
Leonard (19:32):
Do they train from the customer's own service cloud cases? Do they go through the cases and learn what the answers were in cases similar? Is that basically the idea?
Piyush (19:47):
I think so. I haven't got a chance to get my hands on it, but I think so from the preview and the videos that I got to see, it looks like that they are very personalized to that specific org or to that specific user, what kind of usage or what kind of cases that take place. I think it also learns from the cases and everything that the user or that org has. I think this will be very critical because if you are working from home and on Salesforce, you might not get a lot of help from your colleagues. However, something like this would definitely help out in quickly resolving not all of the issues, but some of them. Getting a better response from customer service is always helpful.
Leonard (20:42):
Bill, your company's specialty is the metadata API, right. So the news on that is there is no news, right?
Bill (20:58):
They release a half-dozen or so new metadata objects every release cycle, but they're not really exciting unless you're into the metadata API or deployments. So it's not too much news for us.
Leonard (21:23):
You run a company that deals with deployment and makes heavy use of the metadata API. Other companies do that to help with documentation. There are always gaps in the metadata API where there are things that can only get done with a click. Do you see them closing that gap? Or do you see a data Salesforce having a metadata parody where everything you can do online you can do through metadata?
Bill (22:04):
They're working on it. There's a great webpage that shows exactly what the gaps are across the different channels, as Salesforce calls them. So, if you look at custom objects through the data API, and then through the metadata API - where you look at them through the tooling API - you'll see three different sets of objects. That's what they call channels. These are the ways that the API can talk about these objects. This webpage has different columns of what objects get covered and not covered across various channels. So I think you're right. I mean, there are quite a ways to go, and they're adding in so many new things as well. That's really a big issue.
Bill (23:01):
But there are a lot of smart things you can do with the metadata API. I'll give you an example. We're coming out with a new report that will show you every place that our user gets connected to your org. It'll show you every place that the user's email address gets used in your org. It gets especially interesting if that's an inactive user - since never in the history of Salesforce has there been a way to clean up inactive users. So that's what we're coming out with. It's fascinating, but just today, I noticed some big deal alerts - if there's a big deal, they'll send you an email or whatever. It's not in the metadata API, it's not in the data API, it's just not available. In situations like that, all we can do is really put a not in our product and say, "after we do this for you automatically, don't forget to check your org."
Leonard (24:22):
Piyush, you said there was an interesting thing you can do with URL hacking enlightening when we talked the other day. Can you tell us a little more about that?
Piyush (24:28):
So, another thing that we tested out today was the URL hacking. It's a fancy word for basically pre-filling in forms when you open up a record or something like that. This was a really popular thing in Salesforce classic. What you could do is basically replace the new button with your own customer; in that button, you can plug in a script, which is actually the ID of that. It would pre-fill a form a for you - for instance, in the case that I told you about, the contract date needs to get logged in as six months from the created date, right? On a contract, the subscription and end date and create date is a mandatory field. Not everybody knows to fill in that when you're dealing with new employees or people just migrating to Salesforce. Now, Salesforce is moving that feature from Salesforce Classic to Lightning as well, which I think should have happened a lot earlier - it could have saved me a lot of pain and customer frustration. What you are going to do essentially is replace that same "new" button with your own button, to pre-fill the form in for the user. So, you can pre-fill the record type and pre-fill a number field, or something like that.
Leonard (26:15):
That's nice. That was something that we made use of in Classic a fair amount.
Piyush (26:20):
It's a really minor feature, but it creates a big difference in some use cases.
Leonard (26:29):
I want to ask you both a general question. This was a unique release. Do you have thoughts on what's going on inside Salesforce, and why did they change directions and have to push out Work.com?
Bill (26:29):
Yeah, work.com was very disruptive, and I think some of the new features in the release fell out of commit. I think between those two things ... but they'll be back here, and they'll get work.com done, and it'll all keep rolling.
Leonard (27:15):
Have you heard any rumors about Fall 20, whether it's going to be a more robust release? Piyush, how about you?
Piyush (27:35):
As Bill said earlier, we are seeing new objects like "employees" come into Salesforce. So I always saw a gap in Salesforce. You can use it for sales and everything, but you never had a connection between the HR system and the billing and invoicing system. So, probably on the next release or in a couple of releases, we might see something related to billing. An invoice object would be a very good choice if that could get baked in. So, that's one bit of my prediction that could come true. And we'll be lucky if it does.
Leonard (28:28):
We've got a question here from the comments. Any comments on tooling, API, metadata component dependency?
Bill (28:46):
There's a new API in the tooling API - if there ever was an API with the right name, it's the tooling API. What it does it lets you say, "What is this connected to?" So you can have an object that might be a field connected to another object or used in an Apex script, or that might be a part of a report, and what are all those dependencies. As people know, one of the big issues is when migrating Salesforce metadata, you have dependency issues. If you're moving a custom object, you also have to move the parent of that object, or you'll get an error and won't be able to move it. So the dependency API is potentially helpful for exactly what the questioner asked about org health. You can look at it and see how things get connected and everything that's going on. Great, great question.
Bill (30:02):
I've got a question for Piyush. When you're working with flows, how many versions of the flow do you see that you usually have? Then, if you deploy the flow, are you always deploying the latest version, or are you sometimes wanting to deploy one of the previous versions? Interested in your take on that.
Piyush (30:36):
That's a very interesting question. As a practice, what we generally do is that everything gets developed in Sandbox. The customer tests it out, then we deploy it to production. But on a very practical note, sometimes a customer needs a very minor change. So you can duplicate that version in production on the go when the customer is there with you to test it out right away with the real data. However, you cannot actually create every scenario in Sandbox and then test it out and follow the same kind of flow or deployment practice. In practice, I have seen that there could be about five versions of the same flow with minor tweaks. It's not very practical to always deploy the latest version, even if we might have a minor change when put to use.
Leonard (31:41):
Piyush, is your development practice now to use flows more extensively? A lot of the orgs I end up looking at now have flows, process builders, workflow objects, and Apex triggers, each of them doing similar things - but it just depends on what developer touched it in your practice. What's your discipline for trying to keep complexity down?
Piyush (32:14):
In theory, the practices go with the clicks and not code - this saves everybody a lot of trouble, and obviously deployment and development time. In practice, what happens is that sometimes you cannot judge between choosing a flow or a trigger. That's when the developer would have to decide whether to go with a trigger or with a flow. This brings me to an interesting new thing that is happening with Salesforce, which is the Salesforce optimizer app earlier when we did a deployment, and everything was working okay. We used to download the optimizer PDF inside of Salesforce and show it to the customer - these are the things that will need your attention, like too many administrators in an org, too many triggers, or an old version of an API. Now, this optimizer app lets us see the kind of things that are going on. This is a new interactive feature that has come up in Salesforce. Earlier, it was just a PDF.
Piyush (34:45):
One last thing that I really liked about this release was the split view. So, if you have used Salesforce and the service console, or maybe the sales console, all of your recent items will be on the left-hand side. On the right-hand side, you will see the details of that tracker. Now, they have introduced a new thing called a split view - which is quite interesting. From what I saw on the journey of Kanban, it has improved a lot of things. What I always thought was missing from the main list view was something related to the service or sales console - and now they're bringing that in. It's an interesting thing for a new Salesforce user.
Leonard (35:44):
Yeah, I saw that demo in our user group. That was major. I think we can probably get ready to wrap this up - If you could say a little bit about your companies, once again, and what you do?
Bill (36:18):
Thank you. We build a product on the app exchange called Snapshot. It's a work management tool that a lot of large Salesforce customers use for compliance and security, and for metadata migrations for data migrations. We're all about empowering admins and making their lives easier. Providing visibility into Salesforce is crucial - it can become very, very complex. How can you visualize that? Then, how can you do actionable things given the complexity of your work? So we've got a 14-day free trial. Check it out on the app exchange.
Leonard (37:04):
Piyush, tell us a little bit about what you guys do and how interested people can get ahold of you?
Piyush (37:11):
So, we are definitely partners of Salesforce or just partners at Salesforce. We have three apps on the app exchange. One we recently release was a Shopify connector that connects Salesforce and Shopify. You can sync your data from Shopify and to Salesforce or from Salesforce to Shopify. There are other apps - I was a big fan of Kanban when it got released. So we enhanced that feature and functionality, and we have that app now that supercharges your views using Kanban. We also have a task optimizer app that shows you the pending and upcoming tasks and things like that neatly and easily. The good thing about these apps is that they're free - they're coming out from us because we really love Salesforce and want to contribute to the community.
Leonard (38:15):
Great. Well, that's, that's really interesting, especially a Shopify connector, I bet you people really like that. I'm going to close, thanks to both of you for participating.