Some thoughts about the User Interface.

2 minute read time.
Sage CRM as a consequence of its design is a very customizable system. It is a low code and no-code configurable system. But this architecture that allows system administrators to customise screens and implement workflow with a few clicks and selections means that there are considerable compromises on complete flexibility of control. There is a trade-off between ease of administration and freedom to design the interface anyway we want. ​
 
Having said that we know we have multiple code injection points. We can add JavaScript to the interface to allow the page to appear in any way that we want. For ASP pages and .NET extensions, this control is nearly absolute: You can have it any way you like it but if you want to use certain features such as workflow buttons they can only appear if certain CRM objects are used in the page in certain ways. But for system pages, we are more constrained and the cost in time to overwrite the inbuilt behaviour would typically be unsustainable. You can do it but how much time do you want to throw at the topic.​​
 
I do understand that partners may want to be able to dramatically change how the user interface is presented. But Sage is a 3 tier architecture system. It has its presentation layer, application layer and database layer. However, the objects that we use for example the screen objects (entrygroup block or list block) are simplified to combine the presentation layer (generation of HTML) with the rules and database interaction. You probably are aware that objects like the entrygroup and list blocks have a method called 'Execute'. This is described as a fundamental method and says 'go do the voodoo that you do so well'. The execute methods generate the query to the database, apply the rules and then generate the HTML. We can use other methods to interact with the database and these e.g. the record object give great control over the rules. For example, this may trigger the table level scripts or even trigger escalation rules as data is changed. BUT you would then have problems with workflow as that behaviour is tied to the interface provided by the objects with responsibility for generating the interface.​
 
This diagram is a reminder that the actual interface generated, the HTML returned to the screen is a product of the processing of XML to produce a version of the interface for either the mobile or desktop environments. The chief control of how the product of this processing, the HTML delivered to the browser, will appear to the user is down to the application of cascading style sheets.​
 
I know that some partners do make significant changes to the version of the CSS files that are shipped with the product. These can change the menu structures, the field spacing and general appearance of the screen. The downside of this is that the partners are on their own. Sage does not have the resources to support people who edit the CSS files. ​