Sunday, July 20, 2014

Living in a Bubble

I have been happy in my bubble, where women are prevalent in technical positions, leadership and as developers.

The bubble started when I was in college, completing a computer science major.  My graduating class had the most women completing the computer science major of any class the university saw from that point on, with 45 of us graduating that one year.  Just a few years later, the same university would see 0 women graduating with a computer science major.  Though numbers soon climbed again, they have yet to reach the same peak.  Similar universities have had similar number fluctuations.

Do you see this as disruptive technology or a necessity?
After graduation, I eventually wound up working in the world of nonprofits.  Look around there and you will see women running the show from the top down.  According to the 2013 GuideStar Nonprofit Compensation Report, there are more women than men who run mid-sized nonprofits.  The number of women in IT and database design and administration, at least in the Bay Area, appears to be high as well, from my personal experience.

In addition, women are hailed as early adopters in a lot of technical arenas. A social media study reported by BlogHer found that "Women have an appetite for the latest gadgets and apps," particularly ones that are useful or fun.

So I've been a bit surprised by all the talk about tech companies lacking diversity and failing to employ women in technical or leadership positions.

There is a view that strong teams contain like-minded people, and that may be true if all you want is a strong team, strong enough to plow forward with weak ideas.  But if you want strong ideas, you need to challenge your solutions by creating teams of diverse thinkers who are comfortable defending their ideas, listening to other points of view and adapting to come up with even better ideas.

Innovation springs from a diversity of thought and experience and leads to ideas that can disrupt industries or invent new ones. Remember, problems inspire creativity, so don't be afraid to expose your teams to a broader picture of the problems they set out to solve.

When elevators had able-bodied, human operators the controls were placed at about elbow-height.  The placement of the controls remained the same even after operators became obsolete.  But with a more diverse viewpoint, someone finally designed an elevator with controls at foot level as well as elbow level.  If you've ever entered an elevator with a cup of coffee in each hand or a large box of equipment, you might see the use of this feature for an even more diverse selection of elevator passengers including anyone who has trouble using their fingers for such tasks as pressing buttons.

We all need to leave our comfortable bubbles to learn new things, broaden our points of view and expand our knowledge so that we can develop stronger solutions with broader appeal.  That just doesn't happen very well without diversity.


Wednesday, July 16, 2014

Using Flow Rather than Apex: Performance Tests

Some of the newest Flow features allow for working with collections of records and using a single operation for adding those records to or retrieving them from the Salesforce datatbase.  In the past, Flow could only create or retrieve a single record at a time, but recent features give administrators a visual interface for creating powerful and automated solutions to their business problems using clicks-not-code.

Checking time required and limits for Flow.
As the capabilities of Flow converge with those of Apex programming, administrators will no doubt start handling some of the same tasks with Flow that previously required Apex.  Creating and updating records automatically is a great example of a task that administrators with no programming experience can now manage themselves, for multiple records at a time, with Flow and no Apex code.

But if you have a choice between two tools, it is interesting to see how they compare.  Flow is obviously easier than Apex for anyone not trained to code, while Apex is more flexible.

Benchmarking performance differences reveals the impact of using Flow to replace Apex.  I tested this by coming up with both a Flow and a bit of Apex code to create new records for a custom object and comparing their performance according to feedback from the developer console. 

Performance Comparison


To start, I created a simple bit of Apex code to add 1,000 records to a custom object.  The developer console tracked CPU usage as well as the number of database manipulation language (DML) statements, both of which are performance concerns for anyone watching their governor limits.

I then replicated the code using Flow to add a large number of records to my custom object so that I could compare the performance relative to those same governor limits.  Thanks to the collection variable available with Summer '14, I was able to create a Flow that managed a single DML statement for multiple record insert operations using a Fast Create element.  Previously, this would require a single Record Create element for each new record and so the number of DML statements could become excessive and slow without these new features.

Unfortunately, Flow was more restrictive on the number of records I could manipulate with both the collection variable and the Fast Create element.

For the collection variable, I found that I was only able to hold 499 records with a single variable.  Apex is not so limited with lists and arrays.  This limit meant that I could not create as many records with Flow as I could with Apex.

For the Fast Create element, I was even further limted by Flow.  With Apex, up to 200 records can be insterted with a single DML statement and more records can be submitted with insert operation.  Salesforce automatically divides the operation into multiple statements for blocks of up to 200 records.  For example, 201 records result in 2 DML statements according to the debug console.  My Flow got stuck at 200 records, I could not use the Fast Create when my collection contained more.  Even with 200 records, the debug console reported 2 DML statements being executed for the Flow.

Having to reduce my test size meant that neither the Apex nor the Flow had any measurable use of CPU time.  I look forward to being able to insert more records to better compare performance.

One of the Salesforce critical update messages suggests that enabling governor limits for Flows will have an impact on performance.  You should test your Flows with this update enabled before it goes into effect by default in 2015.

Sunday, July 13, 2014

Leveraging List Views With Salesforce1

The good thing about Salesforce1 is that you have to rethink your user experience and data access for mobile.  Yes, I said good thing because rethinking data access with the mobile user in mind will result in a better user experience for someone on the road than shoehorning everything from the desktop onto a more limited device would.  With Salesforce1, you can provide mobile users with access to data specific to their needs while on the road thanks to Flexipages.

Try something different just for mobile users.
A local nonprofit where I occasionally do volunteer Salesforce development work wanted a mobile app to provide users with quick access to specific groups of records.  These users need to update about 200 or more records a day using a mobile device.  And they want some flexibility regarding the order in which these records might be accessed.

My first thought was to create Visualforce pages that would offer specific groupings of records, but the nonprofit really needed something more flexible.

So I turned to Flexipages to solve the problem.  With Flexipages, you can design a mobile-specific interface that relies on List Views to provide access to specific groups of data.

At their most basic, Flexipages simply define which List Views for a specific object should be incorporated into the mobile experience, including the Recent Items list.  If you can create a List View that prioritizes Accounts Needing Attention, for example, the mobile user can bypass the Accounts Tab and just access that list with a Flexipage.

But Flexipages don't merely offer a single List View, they can combine multiple List Views and Global Actions all in the same screen.  So a Flexipage might offer access to Accounts Needing Attention and Currently Discounted Products all with a single navigation graphic, in addition to a Global Action for creating a New Contact.

In crafting a mobile experience for your users, consider creating Flexipages and putting them at the top of the navigation menu, above the standard tab navigation options like Account and Contact Tabs.  This gives  users more immediate access to specific records of interest to users on the go.

For the nonprofit, I created several new List Views to combine different records on the same page.  I also added an image formula to signify which records had been updated on the road to help the user easily determine which records still needed attention.  You can read more about using images with Flexipages in a recent post.  I also created about 10 different Flexipages to provide the most flexible access to all the records they update via mobile.

Flexipages are easy to create as text files outside of Salesforce.  They are XML files, which are simply text files with specific textual "tags" enclosed in triangular brackets.  For example, "<description>" is a beginning tag and "</description>" as an ending tag, while the text between these two tags would be the actual description.

Once you create a Flexipage, the easy option for deploying them, currently, requires placing them in a zip file with a particular directory structure and naming convention, and including a second XML file listing which Flexipages to deploy.  The zip file can be deployed with Salesforce Workbench using Migration>Deploy.

For more information about creating Flexipages, refer to the documentation here: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_flexipage.htm

Once you consider which data is the highest priority for mobile users, simple List Views, combined with Flexipages, provide the view your mobile user needs to the data they most want.


Saturday, July 12, 2014

When Not To Use Triggers

For administrators who don't code, hiring a developer to create a trigger can be a frustrating proposition, but what else can you do when you need to automate a business process with Salesforce?

Movie props may need triggers,
but administrators can get by without them.
In my experience, many of the processes I need to automate are triggered by a user action on a single record, or are required in order to update a list of records because of a specific change to the database model.  I may change the data model from using a multiselect picklist to check boxes, for example, and need to update all existing records to set the new check box fields based on existing picklist selections for each record.

Salesforce offers Custom Buttons, Links and Actions for updating a single record from the record detail page.  Perhaps converting a Lead to a Contact, for example.  And Global Actions can act on lists of records, such as when I want to create a new field and populate it in all existing records based on existing data.

To define, within Salesforce, the process that needs to be automated, administrators can use Flow rather than Apex.  Flow lets you retrieve records and manipulate them before saving those records, or new records, to Salesforce.  By embedding a Flow on a Visualforce page, it can handle the automated processing and logic associated with the Action or button.  Here is an example of a Visualforce page to initiate a Flow, named "FlowName":
   <apex:page sidebar="false" showheader="false">
    <flow:interview name="FlowName"/>
   </apex:page>
While Flows are easy to use and don't require programming experience, administrators should still learn to think like developers when creating Flows. Beware of using Flows in your production org without thorough testing first!  You can't develop Apex in your production org, which keeps you from damaging your data while you are developing the logic to automate data manipulation.  You should test your Flows in a Sandbox first to protect your data as well.

In the future, Flows will also be able to work with Triggers, but for now, you can have much of the same functionality at the click of a button.

Tuesday, July 1, 2014

Think Like a Developer When You Design Flows

Flows offer a lot of power to clicks-not-code administrators who want to automate processes using record lookup, update and create options offered with this easy-to-use feature.  Of course, Flows do require that administrators learn to think like developers a bit.  They must be able to outline the process the Flow should take, including decision points where the flow might go in one of multiple directions.  They must also think of ways to test and debug their Flows and to create Flows that can be reused or called in multiple ways.
You need to know how to look for bugs in your Flow.

Test Extremes

One rule of testing is to keep in mind the extremes and the improbable.  What happens when users enter data that is out of scope, or when a record that the Flow expected to exist (like a generic, default Account record) has incorrectly been deleted.  Make sure your Flow includes fail-safe procedures and uses error messages, which Flow makes available, to catch these situations.

Break Points and System.Debug

As you are developing your Flow, be liberal with Screens to display the values of variables along the different Flow paths.  One of the things I love most about Flows is the ability to create Screens that I do not tie into the Flow.  This enables me to create break points that halt the Flow before the error occurs and lets me display debug messages for myself between steps, providing the values of variables needed in subsequent steps.  When the Flow is ready to be activated for users, I can first disconnect all of the extra Screens and leave them in the Flow if there is a chance I will need to rework the Flow.

For example, between the record lookup step that assigns data to variables and the decision branch step where the Flow's path will be determined according to variable data, I will create a Screen to display the record ID and all of its variable data.  I won't bother to connect the Screen unless I find that the decision branch does not behave the way I expected.  I can even leave the Screen in place to use as in future versions of the Flow or to use later, when the data model defined with Salesforce objects and fields may have changed (the 'model' part of the Flow).  Otherwise, the Screen stays disconnected from the Flow.

Flow Triggers

For Flows to be used with Workflow rules, they are expected to operate without a user and so trigger-ready Flows cannot have Screens, which require a Flow user to click the 'Next' button to proceed.  This can complicate the debugging process, but don't be discouraged.  When you are first creating a complicated flow, you can still use Screens and simply call the Flow from a link or, to easily pass parameters, a Visualforce page.  See my earlier post for more information about calling a Flow from Visualforce.  Keep in mind that trigger-ready Flows cannot include Screens with error messages and so should be thoroughly tested outside of the workflow rule, to work out ways to avoid errors during the Flow execution.


Deleting the leftmost and rightmost columns
makes this Flow trigger-ready without Screens

Design Patterns

Converting a working Flow that has been created with Screens to one that is trigger-ready and without Screens is easy if you just employ a simple design pattern.  For my Flows, I keep the data and logic elements like decision branches and record manipulation, which you could call the 'controller' or core part of the Flow, in a vertical path down the center of my design.  For the Screens, which you could call the 'view' part of the Flow since that is the part Flow users can see, I push those elements out into columns to the far left and far right of my controller elements.  For example, a simple Flow would have two columns, the leftmost would be Screens only, the rightmost would be logic and record manipulation only.  A more complicated Flow might have Screens on both the rightmost and leftmost columns, like the one illustrated here.

By keeping Screens in their own columns away from the logic, they can be quickly selected within the Flow designer with a single motion and deleted from the design  when you are satisfied with the functionality so that the Flow can be used as part of a workflow without user intervention.

Flows can be executed by Visualforce pages, by other Flows, and by users; with Summer '14 Apex will be able to execute Flows as well.  They can be executed  from record detail pages using buttons, links and Actions; from Tabs, Force.com Site pages and from Global Actions.  Keeping the Flows small and function-specific will help make them reusable in these many scenarios so that you don't have to recreate the same functionality in multiple Flows.  For example, a Flow that operates from a workflow rule and also from an Action on a record detail page might have the 'controller' elements in one Flow that can be called by a Flow Trigger as well as by a Visualforce page that would provide some 'view' context for the user executing the record Action.

Even clicks-not-code administrators can be creative developers once they start designing for multiple uses and considering the debugging process and Model-View-Controller implementation patterns.  And as you become more comfortable thinking like a developer, you may eventually decide to learn more about the Debug Logs and Developer Console.  But with Flow, you might even decide you don't need those to create complex business solutions that work well for your users.