I had great fun writing my recent article "Objects, Relationships, and the Cat” in which I shared one of the things I enjoyed most about working on the Salesforce platform using a rather unconventional story-telling style. In fact, I enjoyed it so much, and based on the positive feedback from readers, I thought I’d do it again. As before, this is a work of fiction with the exception of the technical aspects.

I didn’t really notice that the conversation between my housemate and Angie had gotten louder. I was accustomed to their heated technical discussions. After all, spending several months mostly stuck indoors during a pandemic hadn’t exactly put us in a state of mind to be calm or quiet. Still, I probably wouldn’t have noticed them at all had they not suddenly become very quiet.

Their silence was probably a result of my earth-shattering sneeze. I pulled off my headphones, rubbed my nose, and stared at the cat gazing at me from the bookshelf beside my desk. She didn’t look the slightest bit guilty.

“You didn’t take your allergy medicine this morning, did you?” my housemate asked. I nodded. The pills are the price I pay for us having adopted a cat. I grabbed one and washed it down with some warm lemonade.

“Okay,” I sniffled, knowing that I wouldn’t be able to concentrate for a while. “What are you two arguing about now?”

“My customer has a tough set of requirements with an impossible deadline and budget,” answered my housemate. “And we can’t agree on the best way to approach it. You’ve done enterprise software – care to give it a look?”

“Sure,” I replied. “It can’t be harder than living with the cat.”

“It’s a corporate application,” he started, ignoring my comment. “Nothing special in terms of the database schema – a few related tables with some columns and a straightforward UI—just a few fields. Authentication is easy enough. They use single sign-on through a third party OAuth provider and their corporate users already have accounts. The kind of thing that any web framework can support easily.”

“That doesn’t seem too bad,” I said. “So, what’s the issue? And why did you call in Angie?”

Angie has been our friend since college, and has served as our referee on all things technical since then. This is partly because we both respect her, but mostly because she’s a better developer than both of us put together (although we don't always admit it).

“So, here’s the catch...” my housemate continued. “It's the security requirements. Not every corporate user is created equal. Depending on who they are they may have no permission, read-only permission, or full permission to any table or individual column in the database.”

“Hmm…” I muttered. I decided to see how this would play out. “That certainly adds some complexity to the code. Have you thought about how they might administer that?”

“You’re beginning to see the problem,” he answered. “Setting security for individuals would be tough to handle. So we might put them in groups that reflect common security settings.”

Angie had been quiet up until now – I looked up at her on the large screen where she could usually be found these days on an almost perpetual video conference call. She had an odd smile. “Grouping users might not be good enough,” she said. “You might need to group security settings together and assign them to individual users to provide real flexibility.”

“And that’s even more work,” said my housemate. “The development of the security and configuration is already going to be as much if not more work than the actual functionality they want. And it gets worse...”

I leaned forward expectantly.

He continued, “They also want a security hierarchy – where individual records can be viewed only by specific individuals and their supervisors up the hierarchy. And naturally, they want the application’s UI to fully respect all of the security settings. Lists would only show records that users are allowed to see, and pages only show or allow editing record fields based on that user’s permissions.”

He sighed, “I just don’t see how I can build this thing within any sort of reasonable time-frame or budget. The testing alone will take me days. This is going to take me weeks to build. And I’m already nearly maxed out on work as it is.”

“Okay, so it’s hard,” I said. “But what I don’t understand is what you and Angie were arguing about? I mean, we both know that she’s usually right.”

“Yes, but this time her advice makes no sense at all,” he said. “She said I should talk to you!”

That surprised me – it was quite a compliment.

He looked at me directly. "You’re the one who always seems to have time on his hands – and Angie says, I should talk to you, so… let’s hear it. What miracle do you have up your sleeves?”

I had a feeling I knew where this was going. “Let me ask you something,” I said. “Have you checked to see if they are already a Salesforce customer?”

“No, I…” he started.

“They are,” Angie interrupted.

“Which is, of course, why you told him that he should talk to me,” I said to Angie. I’d introduced her to Salesforce recently and she had obviously done some homework.

I turned back to my housemate. “If they are a Salesforce customer, most if not all of their users already have accounts on their company's Salesforce organization, though as you said, they’re probably authenticating using a third party service – Salesforce supports that. But that means their users are probably already grouped into profiles – users with similar security settings, and into roles – which define a corporate hierarchy. So you don’t need to administer any of that. Just leverage what they already have by building your application directly on the Salesforce platform.”

“That helps a bit,” my housemate admitted reluctantly. “But I don't know anything about Salesforce – even having the relationships defined, tackling a coding project to secure access to tables and columns, and role based access to records, along with the UI security – that’s a lot of work on a platform I already know – I don’t want to think about how much it would be on a platform I’ve never used.”

I leaned back and grinned, but didn’t say a word. He stared at me. Angie just smiled. After a deep breath he finally asked, “Okay, so how much development work would it take to implement these security requirements on Salesforce?”

I leaned forward. “None”

He looked at me in disbelief. “None?”

“Not one line of code. Here, let me show you...”

I opened a Salesforce org and brought up the setup UI for profiles.

“Every Salesforce user belongs to a profile. User profiles are one place you can define access to tables and columns. They are called Objects and Fields in Salesforce. That’s where you define the most restrictive settings. Then, you can use permission sets to grant users additional access.”

“For roles, their positions in the corporate hierarchy, we use role-based security. You define the object as private by default, then you can grant record access using sharing rules based on the role hierarchy or even custom rules.”

“And as for the UI, it’s magic,” I stood up, and in my best wizardly voice chanted “salvum fenestra—a_h-choo!_” The effect was spoiled by another sneeze. “Ah, never mind,” I continued. “The point is it just works. The UI respects the security. If a user can’t see or edit a field, it either doesn’t appear, or isn’t editable. It just works.”

“I had a feeling that might be possible,” Angie spoke up. “I’ve been busy and haven’t had much time yet to dig into the platform, but the amount of security plumbing that they take care of for you seems almost too good to be true.”

“It’s true,” I replied. “The security infrastructure is one of the platform’s great strengths. It allows developers to focus on business processes and use the built-in capabilities for managing, configuring, and enforcing security. That is, assuming you need to do any development at all. For simple applications like the one you are talking about, you may not need any code in the first place. The automatically generated object pages can be customized using the Salesforce UI. And their clicks-not-code automation may provide all of the functionality needed to implement the business process. But if coding is necessary, all the security plumbing – for the business process and the UI_ _– is already done for you.”

My housemate can be stubborn, but he’s not stupid. “You know...” he started, “I was thinking of turning down the job because it’s too much work. I’m going to follow up with the client. Maybe I’ll turn down the job because it’s something they can build trivially on their existing Salesforce installation by their in-house staff.”

He then looked thoughtful, “I wonder what I’ll do with the extra time I gain?”

I pointed at the bookshelf. “How about this time you feed the cat?”

*Published with the kind permission of Dan Appleman