Now we could set up a simple process so Glenn can check the box and just keep everything in sync with the portal list. But the salespeople actually get the requests from the customers, and then they will reach out to Glenn to set up the user accounts. So they’re the ones that are going to click the checkbox.

So how does Glenn get notified? Well a simple workflow would do it. Salesperson checks the box, Glenn gets an email, Sounds simple! Now luckily, this client follows a Rule of Three Process for all changes to the CRM. Rule of Three means somebody from the CRM Management team called the Customer Excellence Department in this case, a department head, and someone from P2 Automation always get together and discuss all changes.

Now if we didn’t do that, the simple thing to do would be put a checkbox on the screen and send off an email. Here’s why that won’t work. For starters, the whole premise here was to give Glenn a simple way to keep track of all the users to have access to the portal. Well in this case, he’s the only one not checking the box. So he doesn’t have control, everybody else has control. That’s a good way to keep this simple process out of sync in a matter of days. Why is that? Well salespeople are salespeople, they sell, they’re on the phone, they’re distracted, they may click the box because somebody asks for access to the portal and then they change their mind on the same call, so they unclick the box. What happens in that case? Glenn gets two emails, or worse yet, Glenn clicks the box, or maybe he clicks the box on several contacts at once. Now he’s emailing himself with unnecessary emails. And worse yet, how does he keep a list of the changes he needs to make? So for example, let’s say there’s a list of 100 users, somebody adds a new one, so it’s 101. Glenn takes a few days off, so he misses the email. He just wants to see a list of all the people he needs to add or remove from the portal. How does he do that? Now he’s got a list of 101 names. Does he go by each one? Does he compare each user one at a time? It just doesn’t work.

So this is what we came up with. In this case, we needed two check boxes. And if we peek under the covers here, you could see we added a checkbox called “Portal Access”, that’s the checkbox we were asked to put in. And another one that’s titled “Portal Access Requested”. So there’s two components here. One, the salesperson asks for a change to be made, and the second component is Glenn makes the change. So we needed two check boxes for this.

And here’s how it works. In this case, I’m emulating a salesperson, JB. JB is going to click the checkbox. Now what this person doesn’t realize is this checkbox is actually connected to the Access Requested field. So we did a little JavaScript to display the appropriate field. JB will click the checkbox, and a message box appears. “Are you sure you want to request access?” Yes. What happens at this point is an email gets sent to everybody that has the portal manager security role. In this case, it’ll be Glenn and Alice. Also the field gets disabled to let the salesperson know the change you requested isn’t instantaneous, it’s in a pending state, someone’s handling it for you.

Now I’m going to put Glenn’s hat on. Glenn’s going to receive an email that says, “Please add the following contact to the portal.” Which contact? We’ll simply click it. Glenn is led right to the record for the contact that wants access to the portal. Notice the checkbox is not checked because this is a different field. This is looking at the actual checkbox field. Now he can set up the user on the portal and when he’s done, check the box. When he does that, the box will be checked on everybody’s screen and the word pending will no longer appear.

Now that’s all well and good, but let’s say Glenn takes a couple days off, it happens once in a while. Instead of rustling through all his emails to try to figure out what he needs to do, he just wants a simple list. Well again, if we had one checkbox, how’s that going to tell him anything? Instead, we gave him a dashboard called “Portal Dashboard”. And note, only users with the portal manager security role can see the dashboard, nobody else needs to see it. This tells Glenn everything he needs to know. Here’s a list of all his current portal users. Here’s a list of all the ones he needs to add, and you can see John Smith is right there. It’s a simple view. This is showing all contacts where the Request is true, but the Actual is false. In other words, someone’s asked for this to be done, but he hasn’t done it yet. And this view would show the opposite contacts that we need to remove from the portal, people that left the company, or for whatever reason, don’t need access to the portal. But Glenn hasn’t removed them yet, they’d show up over here. It’s very simple.

Now the last thing is what happens if Glenn checks the box? In other words, he’s the salesperson. Is he going to email himself? What’s going to happen to the other checkbox? We thought this through. So if you can imagine, this is Glenn’s checkbox, and behind the scenes is the other checkbox. Whenever Glenn changes this checkbox, the other field is set up to match it. So if he sets it to true, the request will be set to true. If he sets it to false, the request will be set to false. And the email only gets sent if the two values are different. And that’s how we did it. It’s using the same technology, simple checkbox, simple email, but since we followed the Rule of Three for this change, we actually made it a little bit more sophisticated and a lot more user-friendly, and most importantly, effective.

If you’d like our help automating your business process, reach out to us today at www.p2automation.com. And don’t forget to follow us on our YouTube channel.