Role-specific requirements - Siebel vs. Web-based CRMs
One of the persistent requirements that I have seen over years in Siebel is to tag editing rights to specific user roles.
A related requirement is to have the fields required for a specific group of users.
For example:
Make “Status” of “Service Request” read-only for service reps. These have to be changed by service managers only
Only back-end system or line managers should update the price on service order, and not all users
Partner number is mandatory for partners, but not when our service reps are entering orders
Back in the days, this requirement led to coders putting their best brains together to create beautiful Siebel eScripts that no one else could understand. Later, this got transformed into performing some kind of circus using user properties to meet the requirements.
Aspect user properties partially address this gap, but they are inflexible since it is burnt in for the release – it is part of the SRF and SRF changes are not welcome.
Even today with the host of user properties and read-only responsibilities, there is no straight-forward answer. The best that developers can do is to nudge towards a solution that they find acceptable, and that does not quite delight the user community.
The term “balance” between the requirements and what is acceptable for product customization seems to imply business has to adapt to the product.
Most of the web-based CRM systems solve this problem rather gracefully.
Take the example of Salesforce.com. SFDC allows complete abstraction of required/read-only properties and allow them to be defined at the role-level (well, it is actually “Profiles” in SFDC). Although you can still define core business logic of read-only/required at the business layer level (or data layer as SFDC calls it), you can still override that behavior at the UI and Role levels.
You can define how each roles view the data. That can mean distinct layout, entities and fields for each user.
Then, you define whether specific fields will be required or read-only in the specific layout.
The layouts are tagged to Profiles, which are in turn tagged to users.
Since the whole configuration is done in the application in real-time, the changes are immediately reflected in the system.
There are two distinct advantages of such a configuration mechanism –
The architecture of making the entire view meta-data driven is fairly obvious. You can make changes on the fly (not really, you have to still plan long term) without worrying about all the new user roles and changes to existing roles till the next “formal release”
Roles are now given proper respect. You allow business to define which role views/edits specific information
This is something simple enough for the product to accomplish as a core feature-set, but powerful enough to matter for most CRM implementations.