A Glance into Concur Configuration: overview plus video demo
We’ve often been asked by SAP users “How does configuration in Concur work? Is it the same as in SAP?”. So, now I’ll try to give you an idea without going into too many details.
In general, it is probably fair to say that Concur is much more configurable than SAP Travel Management – but then in SAP you have BADIs and other options to add custom coding, which gives you the ultimate flexibility (at a cost). As a rule, excluding custom programming, you can do more in Concur, but considering all options with custom code, you’d obviously be able to cover more very bespoke requirements.
The style of configuration resembles the SuccessFactors Admin Centre (but less chaotic in structure) more than SAP Travel Management configuration in the IMG. SAP tries to squeeze everything into tables, which makes it look more homogenous across the board. In Concur, the configuration UI looks more like forms with tick boxes and other fields aimed to fit best the particular bit of configuration (at least in theory).
Most of the configuration can be split according to groups (of employees) and or policies and the main areas to configure are:
- Account assignments
- Forms and fields
- Allowances / per diems
- Audit rules
- Lists (Picklists)
- Report Layout
- Rules / policy violations
- Vendor discounts
- Company settings like allowing upgrade, allowing guest users,…
- Custom Fields
- Vendor Management
- and a lot more smaller things like attendee management, currencies, notifications…
The Audit rules section can be particularly powerful as the exception events it creates can also be sued to control workflows.
For customers, it’s important to understand that not all configuration is open to them, unless they get a special training and certification after go live. So, without certification they can e.g. add audit rules or add entries to lists, but can’t change the expense types or the forms for expense capture.
So much for a quick framework to understand the overall structure. Now let’s look at an example setting up a travel rule. The requirement is:
- The travel policy says: 3 or more employees of the company in the same plane are not allowed for risk management purposes (a requirement to be found in many policies, albeit with a higher threshold). It can be allowed, if it is established that the 3 colleagues are not working in the same field of expertise.
- So, when trying to book a flight, where 2 colleagues are already booked, the system should issue a warning
- The traveler could confirm that it is ok, but then the booking would require managerial approval
Here’s a YouTube video showing how it works: