Separate Developers from Admins
Learning Objectives
After completing this unit, you’ll be able to:
- Explain a developer user role.
- Explain an admin user role.
- Describe how a plugin is enabled.
The creation process for an external client app is not much different than the way you set up a connected app. Use the External Client App Manager in Setup, configure a few basic settings to get started, and enable the plugins that work for your use case.
Divide and Conquer
Before adding plugins, each new external client app is a blank canvas. It has a name, a contact email, and distribution state, but it needs plugins to make it useful. For secure authorization, developers use plugins like OAuth. Each OAuth plugin has some fields that show on the Settings tab and others that show up on the Policies tab.
The first task of an admin (assuming they aren’t also the developer) is to download or deploy the packaged external client app. When this happens, the policies are created for the external client app. These policies are built from the developer-created blueprints in the Settings tab.
Examples of User Roles with OAuth
Robert Bullard is a developer for an independent software vendor (ISV) called Get Cloudy Consulting. Robert’s LinkedIn profile says software engineer, but he thinks of himself more as a generalist, a jack-of-all-IT-trades. The people who hired him made it clear that his goal should always be to programmatically make life easier for everyone around him. First and (as anyone in sales will confirm) most importantly his allegiance is to the sales team.
Just last month, he delivered an app called Swagatron that helps the sales team order swag items that they can give to their clients. The app was a bigger hit than anyone expected, and now the team wants to use their Salesforce data to keep track of which client got what swag and what new items might get customers’ attention.
Developers Develop
It’s time for Robert to create an external client app that will authenticate the sales team’s accounts and provide data to the Swagatron. As the developer for the Swagatron external client app, Robert is in control of the settings file configuration.
To get things started, Robert sets the basic external client app settings like the name of the external client app, the email address for the contact, and a distribution state.
Robert wants his sales teams to have access to the swag data in the local Salesforce org, so he keeps the distribution state local. He knows the OAuth plugin will work best to keep his data secure, so he enables OAuth and configures the basic OAuth settings.
With these settings defined, Robert clicks Create and an external client app is born.
Admins Tune
At this point, Chinua Toure, an admin for Get Cloudy offers to lend a hand. Chinua works closely with the sales team and knows how important Swagatron has become for their customer relationships. Chinua gets admin permission for the external client app, so he can make edits to the policies.
With the external client app in place, the Swagatron app can authenticate the sales team with Salesforce. This means the team members can see all of the swag they’ve given their customers over the years. Because team members will use this app in the field, Chinua wants to ensure that the app is secure but easy to use. Chinua enables the Client Credentials Flow so Swagatron can exchange data with Salesforce without user interaction. He enters the execution user account that Robert set up just for that purpose and saves the policies.
Now, the Swagatron external client app is ready to deploy to the team. In the next unit you look at how you can package and distribute an external client app to an even larger audience.