The Sugar admin console has been around, largely unchanged, for a very long time. It’s a quite simple interface, that gives users power to control a lot of things about the product, users, access training material and plenty of other stuff.
Some of the features of Sugar’s admin console are quite simple, some are complex, and some are just a bit out of sight, and go by unnoticed. Here are some of the items we find come up frequently during projects, and with our own usage of Sugar:
Roles are one of the key features of Sugar’s access control mechanisms. Together with the user Teams, they allow administrators to finely control who can access which modules, which records within them, and also which fields within a record.
Sugar allows administrators to stipulate that only supervising users can delete an Account, only edit leads that belong to one of their teams, or that only sales people can control the status of opportunities, whilst marketing can control a bunch of others.
One thing that Admins should be aware of is that “A user can be associated to any number of roles, and when multiple roles are applied, Sugar adheres to a most-restrictive policy to determine the user's appropriate access levels.” [see here]. So if a user has multiple roles, one says he can access Accounts and the other says he can’t, in effect, he can’t.
Revenue Line Items
One of the key new features introduced in Sugar 7 (Enterprise and above) were Revenue Line Items. Much more than a mere module, revenue line items changed how opportunities work in Sugar Enterprise. With RLI, each opportunity can have multiple lines, each of them referring to a specific component, or product catalogue item, and having a value and a sales stage.
For all its usefulness, you may not want to use the Revenue Line Item mechanism in your Sugar instance. Starting in version 7.6 (out any day now), it can be disabled, reverting the opportunities to function as they did before Sugar 7.
To do that, go to the Sugar Admin Console, hit the “Opportunities” link, and set the “Opportunity Hierarchy” to “Opportunities”, and chose whether you want the “Expected Close Date” field of the Opportunity to be set to the latest RLI’s close date, or the earliest one.
The data from the Revenue Line Items will be rolled up to the Opportunity, but be wary that not everything is preserved (RLI names, association with products, for example, aren’t), especially in cases where an Opportunity has multiple RLI’s. It’s clearly a good idea to demo this in a cloned production instance and taking a close look at the results before moving forward.
You can’t roll back this procedure. If you subsequently re-enable the Revenue Line Item mechanism, Sugar will not build RLI’s automatically.
Web Logic Hooks
Logic hooks are a mechanism that allows Coders, and now, Administrators, to have specific actions be executed when an event happens. For example, whenever a Lead is updated, send it to a Marketing Automation system.
Although logic hooks have been around since the early days of Sugar (earlier than me, anyhow, and I’ve started in Sugar 2.5.1), Sugar 7 brought them out of the code and into the interface. This is good for three reasons:
- Very simple to configure simple use cases, in cloud based environments, and other simpler scenarios;
- Non coding admins get to play too, obviously;
- You get to leverage a tested, high performing, infrastructure, to get Sugar talking with other applications, instead of having to develop everything from scratch.
There are several use cases where this is applicable. Here are some things you can get done with next to zero coding:
- External audit: get another application to track usage and changes to specific modules, or specific records in Sugar;
- Synchronize information with other systems, like an ERP, a project management tool, directories, or others;
- Create outbound integrations with systems that are hosted in the Sugar Cloud, for example, where you can’t access files (yet, at least!), or have limitations on the type of PHP code you can execute.
One thing to keep in mind, though, is that Web Logic Hooks are executed as batch jobs, not synchronously. What this means is that when you change a record, the logic hook that propagates the changes is executed and stores the information in Sugar’s database, but the information is only actually sent when the Scheduler is executed (could be every minute, for example). An inconvenience, perhaps, but one that’s required to ensure Sugar’s stability and performance.
This is it for now! Come back soon, we’ll talk some more about some other Sugar related topics!
DRI has been a SugarCRM partner since 2005, and has 250+ projects based on SugarCRM in one way or another, having become very active in the development of the product itself, with the Open+ Program. We are now Elite partners.