Concur User Provisioning Service: Understanding the differences between Identity, Spend and Travel
Today’s post is the second post in a six-part series made by actual Technical Consultants working at SAP Concur on Concur’s new Identity and User Provisioning Services. The last post served as an introduction to the services, provided reasons why you might want to use them, and explained what employee import record types may be replaced by the new services. Today’s post will explore the different purposes and structures for Identity vs Spend and Travel.
Ok, to get things started, I need to introduce you to a couple of new concepts related to a user’s profile within your Concur system. If you are a long-time user of Concur, then you are probably already familiar with users having one profile for the Expense side of the system and one profile for the Travel side of the system. With Identity v4 a new level of user profile has been introduced. This new level is plainly stated as a user’s Identity Profile. You can think of a user’s identity profile as the base level of user information on which all other user detail is built upon. A user’s identity includes things such as their name, email address, login id, and employee id (among other things). By itself, a user that only has an identity within Concur can log into the system but is unlikely to be able to do much else.
The second change I need to introduce you to is a new term that Concur is using to categorize user data. Concur has started using the term “Spend” to refer to functionality previously known as Concur Expense, Request, and Concur Invoice. In addition, this category now includes all role code assignments responsible for giving specialized user access to the system. These groups mostly represent what has historically been known as the Expense side of the Concur system. Travel is purposely not included in the new “Spend” grouping. It remains separate from Expense and as such has its own set of API calls. With that said, when we refer to UPS v4, we are referring to a new webservice that includes updated API calls for both Spend and Travel.
Ok, now that the new terminology has been explained, I want to talk about the relationship between Identity and UPS in order to help you understand how they can both be integrated into your systems. As stated above, an Identity is the newest addition to the concept of a user within Concur. It was introduced primarily as a method for Concur to integrate with a customer’s own identity management system (also known as an IDP). Say for example, that a new employee was just hired. In order to get that user added to the many different systems that they need in order to do their job, that user needs an identity within the company’s network. Concur’s identity management APIs were designed to interface with those Identity management systems creating users within their own network and Concur in near real time. This can be done because Concur’s Identity APIs conform to the SCIM standard for creating user information and many identity management software systems have already integrated it into their products. A couple of examples of this are SAP’s own IAS/IPS software and Microsoft Azure.
UPS on the other hand was designed to fill in the gaps in a Concur user’s overall profile, therefore giving them the ability to book travel or complete their expense report. UPS is made up of customized extension sets covering Spend and Travel data designed to capture the additional Concur specific information not captured in an identity profile that Concur needs to function properly. UPS was enhanced so that it can also integrate directly with your IDP system by funneling identity updates to Concur’s Identity profile at the same time that it updates both Spend and Travel information. Therefore, it is actually recommended that you use the UPS service for all of your connections. UPS can receive data from your Identity management system, HR system, Financial ERP system, or Business warehouse. Basically, it can connect with anything that is capable of making webservice calls that contains employee related data in a SCIM based JSON format.
You can see a full list of all the field that make up a user’s Identity or UPS user profile at the following links:
Ok, that wraps up today’s post. Upcoming posts will cover the remaining topics referenced below.
- Synchronous vs Asynchronous calls with UPS and how they work together.
- Spend role codes and entitlements.
- V1, Bulk V3 retirement and transition to V4 API
- Best practice and debugging tips for using UPS.
In case you missed the first post, here is a link back to that one.