28 January 2015

API First for Administrators

A couple of Dreamforces ago, when Salesforce launched the mobile Salesforce 1 platform, Marc Benioff discussed the idea of 'API first' at his keynote. API stands for Application Programming Interface and is the foundation for any application to interact with data on a platform. It's a blinking cursor on the screen, waiting for action.

As I looked across the Dreamforce keynote room, I saw sporadic nods and acknowledgments. People appeared to get the idea that end-user applications like Salesforce 1 could be built on top of the API. But for me, it was a profound transformation because it was a very different way of thinking about administration.

API first is way of designing and building features on a platform. It means that before I design a great user experience, I'll prioritize and design the underlying API that the user experience will be built upon. This gives an amazing amount of flexibility; not only can I build user experiences on top of the API, but so can ISVs (Independent Software Vendors who market their applications on the Salesforce platform through the AppExchange) as well as integration specialists. The best part is no data is left behind. Instead of areas of our application being land-locked by a user interface only experience, like View Setup Audit Trail, we'll start with the assumption that data can be exposed through the API and build from there.

Before API first, I tended to believe exclusively in the power of button-click administration. If there wasn't a user experience for me to click, it wasn't worth doing. It was not only easier as an administrator to solve problems with a great user interface but it made ongoing maintenance easier with clicks, not code. A good example of this idea was workflow which can be created without laying down a single line of Apex code. This is still true, even in a world where API is first.

What I realized was that API first didn't mean I had to give up my administrative superpowers to an insurmountable learning curve that is writing "code". It meant that I had more tools in my toolbelt for solving problems, not as an administrator or as a developer, but simply as a person with a problem to solve.

API first also disrupts the way I design and build features for administrators. An example of API first in the administrative world are profiles and permission sets, which are fundamental to managing user entitlements. These setup objects contain a wealth of information about what a user is entitled to do within the context of their organization. But reporting, assignment, and management of these permission containers tends to be challenging.

From a button click perspective, it seems like a solvable problem. I even tried a couple of times, with varying levels of success building the Enhanced Profile List View and Enhanced Profile User Interface. And while the user experience is arguably better, I found it to be a really tough problem to solve from a usability perspective.

The challenge comes from the scale and relationships that define a user's responsibilities within an organization. A single profile or permission set may have millions of permission values. A user may have one profile but multiple permission sets, adding an order of magnitude of possible permission values for any user. And while we often understand a profile or permission set as a black box with a name like "Sales Rep", at a granular level, these permission containers can contain millions of different user rights that our reps need to do their job. Effectively, it's a Gordian Knot problem. And like Alexander the Great's sword that sliced the famous knot in half, as an administrator, my sword is the API.

Profile and Permission Set Schema

As a result of adding more API support for these objects, I've seen incredible administrative tools created in the community like the Permcomparator and the Permissioner. These tools address specific problems like profile comparison and permission set assignment. And even the permission set assignment tool within setup is built using the same APIs that Arkus used to build the Permissioner.

I faced a similar problem with event monitoring. Event monitoring provides an easy to use, downloadable file based API for extracting the same application logs that Salesforce uses to support, audit, and optimize it's own service. While an organization may have hundreds of thousands or even millions of CRM records, that scale is dwarfed by the sheer number of log events that users generate every day. One organization I've worked with generates approximately twenty million events per day or three billion events every six months.

Finding ways of integrating, processing, and visualizing this data is critical. "API first" now becomes "API only" due to the sheer size and bandwidth that this data consumes.

Event monitoring scale is managed by integrating these large data sets into both Salesforce and ISV tools. Whether it's extracting, transforming, and loading the data into the Salesforce Wave platform or into Splunk, customers need to work with billions of events. Because it's exposed to the API first, you can choose whether to simply extract, transform, and load the data into a tool or to pre-aggregate the data by rolling it up and exploring summarized aspects of the data. And once the data is in a more usable form, great user interfaces like Salesforce Wave or New Relic can take over.

While these are just examples of how API first works in an administrator's world, I've found that the greatest barrier of entry for an administrator to work with the API is that it's difficult to start with a blinking cursor on the screen. Before jumping into a scripting language or Apex, I recommend getting your feet wet with a tool that uses the API to interact with data. Many Administrators I know use Dataloader, SOQL Explorer, or an ISV tool like Jitterbit. I prefer the Workbench for a couple key reasons:
  1. It's available on every platform because it's cloud based
  2. It has a swiss army knife's equivalent of important API features including support for SOAP, REST, Tooling, and Metadata APIs
  3. It has a simple and effective user experience that gets me one step closer to the blinking cursor
The second tool that becomes critical is the Salesforce API documentation. This documentation reads like Grey's Anatomy, which is exactly what you need when figuring out how far you can push the envelope with what you can actually do. So an even better place to start is with the SOQL (Salesforce Object Query Language) documentation. SOQL is just about asking questions and getting answers.

Finally, I was surprised last week while talking with a customer about how to get started with the API. They didn't even know which permissions to request from their administrator. The key permission you need is "API Enabled". You will also need at least view access to data. It's easy to start with "View All Data"; however, this escalated permission should be reduced to read on any objects you want to query as you identify specific tasks you want to accomplish. And if you're doing anything with the REST API like building an integration using cURL, I recommend you ask your administrator for a connected app client id and secret. It's a great way to constrain API access for a specific application.

Finally, come up with a list of questions and start simple like 'what are the names of my accounts' (SELECT Name FROM Account)

Example of a SOQL query in Workbench

API first is a disruptive way of administering any system. It doesn't mean that you can't be a button click administrator. Button click administration is still the easiest and best way to maintain the setup of your organization. It just means that, with the API, you might be able to solve a problem sooner while waiting for that perfect user interface to be built. 


Icons by DryIcons

4 comments:

Note: Only a member of this blog may post a comment.