Kris Harrison is a Director of Product Management here at Salesforce. Specifically, he works with enterprise API’s and external services. 

Kris used to be a Consultant with The Gap until his abrupt transition to Product Management. In his past, he also led a charge to begin thinking about services that are called from multiple customer touchpoints instead of standalone website features. In this episode, we’re talking more about his historical experience, what his current role at Salesforce looks like, and some great insights into API.  Listen in to get an angle on the current state of API’s for 2021, including what is going to be retired and what the roadmap looks like.

Also if any developers would like early preview access to the GraphQL pilot, they can tweet Kiril Seksenov (@k_seks).

Show Highlights:

  • How Kris came to join Salesforce’s enterprise API team.
  • What teams within Salesforce he is the Product Manager for.
  • What a “day in the life” looks like for him in his current position.
  • Characteristics of a good API.
  • How developers can use an API effectively. 
  • What a Composite Graph is and how it can help developers.
  • The roadmap for the upcoming Composite Graph API.
  • The problem Kris and his team are trying to solve with the fields function in SOQL.
  • Why the SOQL character limit was recently upped.
  • Why they have decided to retire old versions of API and what those retirement phases will look like.
  • What else is on Kris’ roadmap going into the future.

Links:

What to know about API retirements:

Episode Transcript:

Kris Harrison:
Yes, back in the day, but a large digital transformation for its e-commerce business. And I was asked to augment a new product management team at the gap. And as a consultant, I had never come across that role before. So I asked my manager, I’m like, “Well, what is product management?” And they said, “Oh, you’ll figure it out.”

Josh Birk:
That is Kris Harrison, Director of Product Management over here at Salesforce for enterprise APIs and external services. I’m Josh Birk, your host with the Salesforce Developer Podcast. And here on the podcast, you’ll hear stories and insights from developers, for developers. There, Kris is describing his relatively abrupt transition from consultant to product manager, while working with the gap. There, he also led a charge to think about services that can be called from multiple customer touch points instead of standalone website features.

Kris Harrison:
So at the gap, a lot of my projects were more customer facing features on a website or on a content management tool, but I became ever more interested in the backend capabilities that enabled those customer facing features. And so I gradually took on more technical projects, more backend focused projects, and eventually that led to contributing to the company’s burgeoning public API program, where the underpinnings of these customer facing features were the product unto themselves. And so that directed my domain focus towards APIs and I had that itch again to be able to be connected to customer problems that were of different industries. I had been in retail for a long time in e-commerce and I was curious about new problems trying to solve. And Salesforce is in the mix of many different company and industry problems of various sizes. And so that opportunity to reconnect with more diverse problems was appealing to me at that stage of my career. So an opportunity to join the company’s enterprise API team came my way and I joined in June of 2019. And I’ve been here ever since.

Josh Birk:
Gotcha. And to level set, what specifically are you at PM for?

Kris Harrison:
So I’m the product manager for a few different teams within our platform services area. The first is called the Enterprise API Team, and we oversee the SOAP, the Bulk and the REST APIs that enable access to that core data in Sales Cloud, Service Cloud, and a few other Clouds. But I’m also the PM for our external services product, which allows for the registration of non core APIs, REST APIs to expose them out as declared a building blocks in products like Flow. And so I’m on both the API production side of the house, as well as the API consumption side of the house, in my role within platform services.

Josh Birk:
And I’m going to guess that that is beneficial because you get to see both sides of the fence. So you know what gaps external services might be filling from a customer point of view versus what the rest or the Bulk API might be doing.

Kris Harrison:
Yeah. I mean, the thing about external services is that we need to reckon with the ongoing evolution of API standards and how different companies are expressing their API through that standard. Even though there’s a specification, there’s a lot of variability or fluidity that we need to be able to reckon with on the Salesforce platform in order to expose those operations and those schemas out to be made use of through call-outs to those APIs. So it’s neat to be able to expose to what other developers, other companies are doing with their API and match that up with the best practices or the standards that we hold ourselves to for our own API. So it’s a really neat place to be.

Josh Birk:
Nice. And I just have to give you a shout out because external services have come up multiple times, this is a developer podcast, but yeah, it is so convenient. The episode that is about to come out as we’re recording this with Richard Clark, talking about Slack integrations, under seeing, using it with flow. And then of course, when I was talking to Tony about open APIs and how things like Swagger really benefit from that kind of stuff. So it’s clearly even for the developer audience, obviously being really useful. Okay. So I ask every PM this partially because I always get a different answer. And this is a fuzzy question I say, day in the life, but maybe a week in the life is a better way to put it, but what is a day in the life like for a Salesforce PM?

Kris Harrison:
Oh man. Well, for me, I’m working with two engineering teams. And so what’s common is the agile practices to continue to drive forward on the scope that the teams are charged with. And that’s a mix of the user stories that enable, the key features that we’re targeting for a particular release, the bugs that we need to address in order to continue to support customer success and also participate in high severity support cases that make their way to the engineering team, for which the support organization needs additional help to uncover the root cause and the path forward. So there’s always that mix of activity going on. But as a PM, given the core Salesforce release cycle you’re always spending time on the release that’s currently in development while also supporting the rollout of the current release and getting the word out and working with marketing to make sure that the new capabilities are well understood and are able to be adopted.

Kris Harrison:
And then there’s that, well, there’s another release we’re going to have to start working on in a few months, so I need to make sure that my roadmap is up to date and the things that I’d like to address in a future release are lined up. So that the team is always being kept up to date with the highest priorities and that those priorities are well understood and are actionable by the engineers because their time is so very precious.

Josh Birk:
Yeah. The phrase I think I keep hearing is move fast and don’t break anything.

Kris Harrison:
Yeah. I mean, don’t break anything in production. We can break things in pre-prod while we’re developing bugs are good until they get out to production.

Josh Birk:
They’re good as a learning exercise. Got it. Okay. So speaking broadly, and I think you touched on this a little bit, when you’re talking about the balance between consumption and creation with the APIs. And I don’t think developers think about this that much because they are kind of the consumer of the API, but what are characteristics that you would attribute to a good API?

Kris Harrison:
That’s a good question. So that was actually something that I draw upon from my days working on customer facing features and solutions, which is, it should be easy to understand, it should be usable, the core tenants of a product, be it software or hard good, are that it needs to be usable, it needs to be friendly to the end consumer. There need to be well understood affordances and good experiences that emanate or are resonate with that product. So the same core tenets that apply to a cup or a phone or a computer should be adhered to for an API. So I think just not thinking about it in such a super special or technical way is important to keep in mind. And what helps ensure that, in the case of APIs, are these specifications that serve as guides to make the capability, the shape, the interaction with that API, something that you don’t have to relearn from company to company or from platform to platform.

Kris Harrison:
And that what the API is known for is the unique domain capability that your business is known for to be consistently or usably expressed through that API.

Josh Birk:
And flipping that around a little bit, what are some things that developers should be considering to really use an API, especially an API like ours, like the REST API effectively?

Kris Harrison:
One of the things that I’ve tried to espouse back when we were doing conferences was to think about your use case, and for an API as extensive in capability and reaches sales forces to not jump into the first resource that you connect with. To be able to appreciate how many options there are at your disposal, and that you really need to connect with the right API for the job that’s at hand. And there are a lot of different ways to address a given use case through our API, which is great and awesome, but the burden does fall on the consumer, the developer, to be able to future proof their integration and make sure that they’ve evaluated the other options at their disposal. And the company I think is doing a great job at getting more tools, getting more resources out there in order to be more effective and efficient navigating this large API surface.

Josh Birk:
Yeah. Back when we were doing things like conferences and traveling, and I would talk to people less than six feet away from me. One of the things that, I think it’s improved, and I know that we’re crossing the bands a little bit here, but one of the tricks on our platform, that always surprised me that many developers did not expose themselves to was Apex REST. And it’s like the number of times, people just assumed the REST API, hit the API, get some stuff, just keep hitting the API for these very, little bits of actions at a time, but we’ve got some modern tools to help with that as well. For instance, what’s a Composite Graph and how can that help developers be more effective and efficient?

Kris Harrison:
Yeah. The Composite Graph API is the most recent addition to the composite family of rest resources. And it’s purpose built to allow a developer to organize a large set of related under seeing into a graph and really eliminate the need to have to write extra code, to orchestrate the relationships amongst those records and develop a well-structured payload of relationships and operations that can be sent to the server. And then we’ll figure out the most efficient way to process that payload and do so with the confidence that any issues that are encountered along the way won’t result in an incomplete or partial transaction. And so we’ve studied a number of usage patterns with the existing composite resources. And as you made mention, Apex REST offers a lot of capability and customization, but that doesn’t tell writing code. And so we found that Composite Graph is well suited to really focus on the unique nature of the integration and not having to repeat these orchestration patterns over and over and over again.

Josh Birk:
Yeah, because I used to fall into that pattern of writing data structure as an inner apex class, sync that up to JSON et cetera. And it’s like, there’s a little bit of business logic involved, but a lot of it is just handling those relationships. And it sounds like a Composite Graph can really replace something like that.

Kris Harrison:
That is the motivation. It’s something that we reckoned with internally as different teams are building new features on the platform. But given our purview is enabling capabilities on the platform for all developers, we recognize that that opportunity exists for other teams to make use of outside the company. So we’re drinking our own Composite Graph champagne while also pouring it out for everybody else.

Josh Birk:
Nice. What’s the current state of the Composite Graph API and what’s the roadmap looking like?

Kris Harrison:
So Composite Graph went GA in the winter ’21 release, and it was demoed in a few different forums last year at TDX and a little bit more during Release Readiness Live. and so it’s available for synchronous operations. The graph payload is something that we believe can be submitted to Bulk API 2.0 for asynchronous operations at a larger scale. And that remains in a closed pilot. So if anyone’s interested to try that out, reach out to your account team and ask them to nominate you for the pilot, but we believe that there’s a use case or a set of use cases that can be satisfied with the graph payload through both as well. So that’s something that we’d like to do in upcoming release, but we want to gather a little bit more feedback through the pilot before we push that to GA.

Josh Birk:
Got it. So another thing that just went GA is the fields functionality for SOQL what’s the elevator pitch for that?

Kris Harrison:
So the problem we’re trying to solve with the field’s function in SOQL is to make it simpler and more straightforward to explore the data in an org without having to do a bunch of research or to type out a long, extensive involved query statement. And we believe this is the beginning of a capability within the software language that will lend itself to reuse of other platform constructs that organize sets of fields for other purposes. So we went out the door in the last release with a pretty simple set of options of all custom and standard. And we believe that there are a lot more opportunities to add to that list of field options and in future releases.

Josh Birk:
So let’s dig into that a little bit. So for instance, select all, sounds a lot to me like select star, but what are some of the distinctions and why not just go a like select star route?

Kris Harrison:
Extensibility, select star is a well-known pattern in other career languages, but we believe that we can do better and more in just establishing career language parody. So there are some situations where all the data, all the fields are of interest, for a particular use case, but that’s something that needs to be very cautiously developed against, in an integration with a platform, because there’s a lot of resources that would need to be drawn from, in order to retrieve and work with that kind of payload. So if you need all data, you’ve got a cheap and cheerful option, well, not cheap, but you’ve got to, depending on your perspective. But caution, need to be taken to ensure that kind of uses and an anti-pattern that would put the integration at risk. But if you’re writing some queries while you’re managing your org and you want to see the data model in the context of the data itself, this is a pretty handy tool for that.

Josh Birk:
So back in the day, I would also, people would, especially back my workshop days, people would always ask me, why can’t we use select star? My diplomatic response was something along the lines of, if we offered select star, everybody would just use select star to always get all the fields. And eventually in a multi-tenent system, that’s just going to break down performance. So is that statement no longer true in a select all world? Or are we putting in limits and guard rails to make sure that you’re not burning down your neighbor’s house by using select all? And as you were just saying in an anti-pattern situation?

Kris Harrison:
There are absolutely limits in place and they’re well-documented in our developer guide. So with great power comes great responsibility, but also launching this feature, we want to get feedback on the specific applications of it and learn about the degree to which these governor limits initially out the door are enabling or holding back the use. So we can evolve, and we plan to evolve from this initial posture in our spring GA and go from there.

Josh Birk:
Nice. And looking at the documentation and your blog posts, I think it’s hard to visualize on a podcast how much simpler queries turn at this point, because the number of times, I do need all the standard fields, but I also want this one custom field or often vice versa. Because the only things that are interesting to me on that object, especially a custom object, maybe the custom fields that I just added to it. And it’s like, that’s 12 characters now, instead of every single field being put down into a character limited list.

Kris Harrison:
That I’m glad that it resonates with you.

Josh Birk:
That being the goal. Speaking of character limits, we recently up the soccer limit from 25,000 to 100,000. What was the impetus for that?

Kris Harrison:
There was room to grow with some of the underlying database constraints. And as the platform, as more as us of the platform, some of these limits are always up for re-evaluation and the current limit was just holding back some more interesting use cases and scenarios. And so we took a look at what the database could do. There was room to grow. And so we expanded that limit. So limits are very, we talk about limits a lot and why they’re in place and why they’re important, but they’re not static, they’re under ongoing evaluation by the teams that have them within their purview. And that’s especially true with our enterprise API team and on the external services team to expand or relax or evolve the nature of those limits as we move forward.

Kris Harrison:
So yes, we did that with softball character limit that’s on the other end of the spectrum with what fields allows for, but the combination of the two can really open up a lot of interesting query patterns as is needed. With API request limits, we transitioned to a usage based entitlement last year that allows orgs to actually exceed their daily allocation when there are spikes or unexpected usage patterns that come up that would otherwise just outright be blocked. And we recognize that that’s not good for integrations that are peaking or have evolving usage patterns and we could do better. So we did.

Josh Birk:
Yeah. And that’s a brilliant one because there’s so many developers I know who have run into that just out of pure kismet, like it wasn’t a design flaw, they’re not trying to beat on the server or anything like that. And the number of times I’ve been in a hackathon and I’ve had to go ask a PM to please take this D org and flip the 24 hour limit again, so that’s a brilliant perspective. Looking behind us a little bit here, it looks like we have some version retirements coming up, first of all, I feel like retiring anything at Salesforce, any feature, any API version, anything is a big deal because we’re potentially impacting a large number of enterprises. What goes into the consideration for a move like this?

Kris Harrison:
There’s a few things. Number one, we look at the consumption patterns. So there’s definitely a longer tail of usage for our older API versions. The API version retirement program that is about to reach its next major milestone is affecting version seven through 20 of SOAP, Bulk and REST and version seven went live during the summer 2000, summer ’06 release. That’s quite a long time ago. And there are some orgs that are still making use of it, but the majority of orgs are on much more recent versions. And it’s not for free, there’s cost associated with maintaining those older versions. And we would much rather direct our resources towards building new features than keeping up really old versions that are not as feature rich as the more current ones. But we’re also managing through this very thoughtfully and carefully making sure that the retirement efforts are well understood, well communicated for making use of new features that launch within setup, like release updates so that this retirement is within the same level of visibility as other changes to an org.

Kris Harrison:
We’re also using this as an occasion to provide more and better insight into the API consumption of an org. So in summer ’21, there’ll be additional insights that can be gleaned of API requests coming into an org that will be in support of this retirement program. But also more generally just getting a better handle on who’s making requests of which API, which version, what kind of operation, to better manage what goes on in an org.

Josh Birk:
Got it. And so one milestone’s happening in summer ’21, what’s happening in summer ’22?

Kris Harrison:
In summer ’22, we will stop version seven through 20 from being accessed and we’ll stop support for versions 21 through 30. So we’re going into a very gradual retirement phase, where the first milestone in a summer releases end of support. And that following summer will result in the end of the access, the end of life of that version or those versions. So it’s a pretty long lead time, but it’s meant to help support any migrations that need to happen to adopt the more current versions.

Josh Birk:
And so in that far off future where I have my 2006 version seven, I’m trying to think of what I would have used, the 2006 integration with probably flex, I don’t even want to admit to that right now. So, but anyway, if I have that integration and I have neglected all warnings and boldly gone ahead without doing anything, what am I going to see when my implementation is no longer going to be able to access API server?

Kris Harrison:
You’ll get an error response.

Josh Birk:
What’s in that error response to let me know what I’ve done wrong.

Kris Harrison:
It’ll be error code that indicates that the resource, so the operation is gone and no longer available.

Josh Birk:
Got it. Okay. And to be clear, and just as rounding it out, this is everything, so if it’s data loader third-party integration, anything that’s pinking that end point is going to be impacted by this?

Kris Harrison:
That’s right.

Josh Birk:
So where can people go to learn more about this? I think we’ve got some help docs on it, is there any other documentation on migration advice or anything like that?

Kris Harrison:
Yeah. The best resource is the knowledge article that represents each of the two retirement programs that are in flight right now. And they’re both, we’ll the first one is able to be accessed from setup, from release updates. So don’t even need to wait for the show notes, you can get to it right away from setup.

Josh Birk:
Got it. Nice. Okay. So instead of looking behind, let’s look ahead a little bit, and you’ve mentioned a little bit here and there, but is there anything else from the roadmap that again, safe harbor, forward looking statement, asterix, theoreticals, et cetera. But anything that you’re thinking about that you want to give a shout out?

Kris Harrison:
I want to give a shout out to some work that other teams within the company are doing with respect to Graph QL. So we talked about Composite Graph, which is a very Salesforce sObject oriented organization of records for CRUD, but there’s also energy going towards Graph QL, which is a query and data manipulation language an API specification that is supported with a suite of open source tooling that allows you to operate over a specific single end point. This is an API that Salesforce is exploring. There’s some developer previews that are ongoing and the team’s starting to recruit other developers to participate in those previews to get some feedback and understand how well it’s working before we open it up for more public access.

Josh Birk:
Got it. And that’s our show. Now, before we go, I did ask after Kris’s favorite non-technical hobby. And again, turns out to be something that’s a favorite among coders.

Kris Harrison:
Learning to play the piano. I’ve been taking lessons for a few years now, and I find that it is a really wonderful way to learn the language of music, unlike a programming language. Just a very different set of rules and applications that connect with through a different kind of keyboard. So that’s been my hobby and it’s almost like meditation almost because you can’t really think about anything else when you’re practicing music. So it’s a nice little escape and a good hobby.

Josh Birk:
Nice. I want to thank Kris for the great conversation and information. And as always, I want to thank you for listening. We’ll have more information about what Kris is talking about in the show notes. And speaking of show notes, if you would like to learn more about the show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see those show notes and have links to your favorite podcast service. If you’d like to learn more about me, I am on Twitter @JoshBirk. And I am also on Twitch @JoshBirk, where we do a weekly fortnight charity game. Thanks for listening again. And I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.