“Sure, we can do that…but it’s going to require some code.”
…and then there’s silence in the conference room. It’s a new challenge for developers working in a declarative (i.e., point-and-click configuration) world. It used to be that code was the default answer for any feature request but that is no longer the case. When a business signs on to a platform that hails the “Clicks Not Code” mantra, introducing any custom programming can be perceived as a requirement of last-resort and sometimes even a failure of the platform.
Addressing this initial reaction looks to the following:
- It’s the job of every business analyst to identify what features will provide best (aka easy to understand, fast to use, etc) experience for their users.
- Many of those requirements are very unique to a company.
- No platform provider can accurately predict or deliver EVERY custom business process in a point-and-click configuration strategy.
Salesforce.com recognizes this and provides three avenues to get any business to their end-goal:
- The Idea Exchange lets customers tell Salesforce.com what they think should be considered widely useful features (not company-specific).
- The AppExchange lets other Salesforce partners add features that a benefit a subset of customers.
- The Force.com platform puts the power in the hands of the customer to accomplish just about anything else.
Evaluating the options, there are times when custom code with Force.com turns a complex, multi-step, unique business process in to a one-click user operation. Those efficiencies are just too compelling.
The Developer Challenge
From the developer’s perspective, these choices require a new mindset not present in the traditional application development model. End-users are always considered as the project’s customer. However, the declarative platform can also put a system administrator squarely at the front of application delivery. That person, the master of clicks-not-code, needs to implement every new feature in the system, and every new piece of code (triggers, Apex, Visualforce, etc) can be a sacrifice of control.
Strategies
It’s no surprise that Salesforce.com gets that too. Their success can be attributed to putting control in the hands of administrators. At the same time, they’ve provided tools to let developers do the same. Any time an administrator can make modifications to a custom-coded solution without developer involvement is a winning scenario (and don’t worry, the developers will stay plenty busy). Writers Note: I’ve sometimes referred to this as the “Don’t Call Kevin” consulting model. The logic: if customers don’t need to call me for feature configuration updates, they’ll want to call me for their next project. So far, so good.
Tools
So, when starting new custom features, it benefits everyone when the developer has a good understanding of the tools available. Here are a few:
Custom Settings: Rule number 1, hard-coded values embedded in code is bad. Custom settings give you the ability to define your own configuration for a feature. Use them to designate specific id values (e.g., a trigger is watching for a specific recordtype id), numeric limits, important picklist values, or flags that enable/disable certain features. Settings support both List and Hierarchical formats: hierarchy settings are particularly valuable (IMHO) since they let you create settings that vary among different users or user profiles…very handy when functionality needs to change among users. Settings can be referenced in Apex classes/triggers (using Setting_Name__c.getInstance() ) and Visualforce (using the {!$Setup.Setting_Name__c.Field_Name__c}). And a bonus for administrators: hierarchy settings are available in the declarative world: custom links/buttons, workflow, validation rules, etc. Learn more about Custom Settings here and here (thanks Jeff Douglas).
Custom Labels: Rule number 2: hard-coded values are still bad. Any time a developer needs to put hard coded text in a Visualforce page (field names, instruction text, notification messages), the administrator has lost the ability to make changes to that text (and, oh yes, it will change). Take all that text and put it in custom labels instead. Then reference them from Visualforce with {!$Label.label_name} or Apex with System.Label.label_name.
Field Sets: Page Layouts are the weapon of choice for administrators. Adding a field with drag and drop (and no developer contact) is empowering. To an admin, replacing a standard page layout with a Visualforce page can be like removing a thumb. Fieldsets are no match for the capabilities of page layouts, but they DO give some control back to admins when adding and removing fields on a page. Just define the fieldset within the object setup, and reference that fieldset on the Visualforce page. Fields added or removed from that fieldset will be instantly reflected on the page. Writer’s note to developers: fieldsets are not yet reachable from Apex code. That means that they’re most useful when referenced by the standardController variable where you don’t need to specifically query a field from a custom controller/extension in order to display on the page. More on field sets here.
Visual Workflow: Finally, the sleeping giant. Flows were introduced several releases ago as a paid feature addition. With the Spring ’12 release, Visual Workflow quietly became a free tool with Enterprise and Unlimited Edition. With it, admins can create application functionality with wizard-like user interfaces and configurable decision logic…and all in a graphically-presented configuration format. Developers now have the ability to design functionality within Flow and leverage their coding prowess to embed those flows within Visualforce (or enhance with Apex). It’s the ultimate marriage between administrator and developer and will re-define (again) how applications are designed, delivered and maintained. Learn more here and watch the webinar here.
More to Come
While one article can’t provide much depth on any of these tools, each topic has enough to discuss in their own posts. Do you want to hear more about a specific topic, or do you have more strategies that make admins smile? Leave a comment and ask for more.
A great example is the force.com labs’ Public Knowledge Base 2 (PKB2) on the AppExchange. Almost every field label is a Custom Label. There are many Custom Settings — which are managed through the App’s Visualforce “setting” page.
The only qualm I have with Field Sets is the scenario that the admin removes a field required by the code to be populated. I would imagine the best practice is to “hardcode” that field on the page and rely on Field Sets for everything else. Or perhaps some friendly Apex message warning that a required field is missing?
Great point, Brian. Configuration options are essential when putting solutions on the AppExchange since every customer will use it differently.
And yes, it’s a dangerous setup to have Apex code rely on fields within a field set. If it’s referenced in the code, then best off including those fields as rendered=”False” inputFields.
Some specialists argue that credit loans aid people to live the way they want, because they can feel free to buy needed stuff. Furthermore, a lot of banks present collateral loan for all people.