Showing posts with label Visualforce. Show all posts
Showing posts with label Visualforce. Show all posts

Saturday, June 11, 2016

More Better Bots

You know Auntie Pat Tern loves Jeopardy!, the tv show with all the answers, but we have an old friend named Eliza who believes we can find all the answers we need by asking ourselves the right questions.  My developers have been asking some of the right questions since their recent trip to the TrailheaDX conference (a conference for Salesforce Developers, similar to past conferences in 2007 and 2010).

First of all, the developers asked what we should do about all of our existing Visualforce pages now that users are craving Lightning Experience.  "What can we do to give them that look and feel without a wholesale rewrite of our UI?" they asked.  Their questions naturally led them to the answer that we should start simply with applying the Lightning Design System to what we have in Visualforce, as a first step.

Next, the developers asked what was going on with Salesforce and AI.  "What's the deal with bots?" they wondered.  While they mulled this over, I reached out to Eliza to see what she had to say:
> Hello. My name is Eliza.  How may I help you?
* Eliza, what's the difference between AI and machine learning?
> Ahh.  Please continue...
* Really, I have three issues: Artificial Intelligence, Machine Learning and Natural Language Processing.
> What does that suggest to you?
* Like Steve Wozniak said at TrailheaDX, Artificial Intelligence is nothing without Machine Learning.  Natural Language Processing benefits from the ability to learn better responses.
> I'm not sure I understand you fully.
* Well, GA Tech has done some cool stuff with bots.  One learned to answer frequently asked questions for students.
> Can you elaborate on that?
* For a class that prompted over 10,000 online questions per semester, the professor used Machine Learning and trained a bot using questions and answers from previous semesters.  The bot was set to respond to those familiar, frequently asked questions and to only respond to new questions if it calculated a 97 percent or higher confidence level for its answer.
> What does that suggest to you?
* It suggests that I can blend Natural Language Processing and Machine Learning to provide automated, interactive responses to FAQs.
> Say, do you have any psychological problems?
* Um, I do sometimes chat with bots.
Having a bot that can help customer service agents provide the best responses to Cases would help our service team reply quickly and consistently.  We also might want a bot to help provide strategies for the sales team, following the department's best practices. Bots, with the ability to learn from our org's data and best practices can also help us guide new employees and reduce their frustration.

Auntie Pat Tern doesn't really like the term "Artificial Intelligence" because she believes that using code to process our human questions and requests is genuine intelligence.  And our old friend Eliza is curious to know how you feel about that.

Friday, December 5, 2014

Get Ready Glossary for Administrators Learning to Code

If you are and administrator learning to code, you already know more than you may realize.  I've started preparing a glossary to help you with programming terms by giving you similar examples from your daily tasks as a Salesforce Administrator.

Database customization and coding, it's all connected.
  • Data Types:  When you create custom fields, you have to specify a data type: Date, Text, Currency, Number, etc.
  • Polymorphism:  When you use "+" in a formula for two text fields, it concatenates, when you use it in a formula with two number fields it adds them.  This different behavior in different scenarios is polymorphism at work.
  • Variables:  Fields that let users input values are variables.  They can be changed if needed, just look for the label you gave and edit the data.
  • Constants:  Your org ID is a great example of a constant.  It's a value that will not change in your org.
  • Objects:  Okay, this is confusing.  When you start programming, you will see that Salesforce objects are now referred to as SObjects.  This is because object oriented programming languages use the term Objects to represent data collections.  Oh, hey, that's what objects are in Salesforce too, basically.  Only oop objects can also have actions related to them, things that you can do to them or things that they can do to other objects.  Oh, hey, sObjects are the same if you think about workflows as actions that are related to specific objects and think of triggers as actions that let one sObject act on another sObject.  So maybe this isn't confusing at all.
  • Array:  In the Salesforce database, you have a record ID associated with a bunch of fields -- record name, created date, etc.  This is essentially an array of data. Apex uses the term List rather than Array, but they are the same.  Lists can be multidimensional too.  For example, you can have a list of data from fields for a single contact record, or you can have multiple records in a list and each of those records will have its own list of field values.  List Views are two dimensional lists of data.
  • Cast:  In programming, you can force a variable of a particular data type to be treated like a different data type.  Similarly, in Salesforce, you can use Formulas like Text(PicklistSelection__c) to force a field, in this case a pick list, to be treated like a different type of data, in this case Text.
  • Model-View-Controller:  This is easy for you.  Model is the data model.  When you create custom objects and fields in Salesforce, you are changing the data model, native objects and fields are also part of the data model.  View is the user interface.  When you edit page layouts, you are changing the view.  Controller is any automation.  You might add workflow rules or formulas to affect data based on rules and reasons you define.
  • Boolean data: Think of a checkboxes.  They are true or false, checked or unchecked.
  • Boolean Operators: And, Or.   You may be using these in formulas or in list view filters already.  If you look for this value AND that value, both must be true.  If you look for this value OR that value, only one of them needs to be true, but both true will work as well.
  • SOQL: SObject Query Language lets you express in a few words the kinds of information you already use defining List Views.  For a List View, you sepcify filter criteria for selecting specified fields from the given object.  You might select First and Last Name from Contact with filters looking for records where the phone number is blank, for example.  SOQL lets you express the same sort of thing when programming in Apex, using a few key words.

If you want to write code for Salesforce, Visualforce will handle the View portion, Apex will handle the Controller portion, and Salesforce will continue to handle the Model portion of your program.  You will probably find yourself using data types you are very familiar with from Salesforce fields as you set up variables and constants.  And you will find SOQL easier to understand if you think of them in the context of list views, returning lists or arrays of data you request.

For a more complete introduction to programming for the administrator, please watch this Dreamforce session on coding for non-developers: http://dreamforce.vidyard.com/watch/haqgdyryAtDoQdMsOieTTA

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.

Friday, April 18, 2014

Salesforce Flow Using Record IDs at the Start or at the Finish

Salesforce Flow can be combined with Visualforce pages to provide greater flexibility and automation to the user interface so that Salesforce users have fewer opportunities for mistakes. 
Racer X doesn't always like to start with the group.

 

Start

By invoking a Flow through a Visualforce page, you have the option to create a button on the particular object you intend to manipulate.  In this example, a button on the Lead object is configured to access a Visualforce page that invokes a Flow to convert the Lead.

Because the button exists on a specific record detail page, the standard controller makes the record ID accessible for the specific data being displayed when the button is clicked.  This means that the record can be converted without additional Apex code.  The Visualforce page would look something like this:

<apex:page standardcontroller="Lead" >

    <flow:interview name="LeadConversion">
            <apex:param name="thisLeadID" value="{!Lead.Id}"/>
    </flow:interview>

</apex:page>

 Finish

Finishing the Flow by bringing the user to a specific record detail page is more difficult. The easiest solution by far is to provide the information and actions the user needs as part of the Flow rather than as something they see after the Flow is finished. 

But even the complicated solution, adding Apex code to a custom Apex controller or extension to specify a finishlocation, is not too difficult.  Simple code enables Salesforce Flow to finish on record detail page. Even so, there are some considerations for defining a finishlocation:
  • Visualforce is required to specify a finishlocation and only URLs in your Salesforce instance can be specified within the finishlocation attribute on the Flow according to documentation
  • For variable finishlocations, an Apex controller is also required
  • Rather than referencing variables as part of the finishlocation, use a variable in place of a finshlocation on the Visualforce page
Here is a simple method to add to your Apex controller code to use a specific record ID in the finish location:

        public PageReference getpRefFinishLocation() {      

            String temp = 'home/home.jsp';
            if(myflow!=null) temp = string.valueOf(myflow.RecID);
            PageReference pRef = new PageReference('/' + temp);
            return pRef;

        }

Use code like the example above to access a variable, RecID in this case, from your flow and incorporate that into the URL for the page users see when they finish executing the Flow.

Monday, December 16, 2013

Advanced Data Manipulation With Flows

Salesforce Visual Flow provides a relatively easy means to design task-specific user interfaces for end users to interact with data.  But it is important to note that Flow data is not permanent and exists only during one user's execution of the Flow.  You easily can connect Flow data to your Salesforce database, Visualforce pages and Apex code as well.

See my previous posts for more information about how Flows can simplify difficult processes for Salesforce users and tips for styling Flows

Record Lookup

Don't forget to save data if you need it!
If you intend for users to save the data, it can simply be written to Salesforce via the Flow data creation elements.  Similarly, there are elements for retrieving, updating, and deleting Salesforce
data. 

One of the important elements for connected Flow data to your Salesforce database is Lookup.  You can use the record lookup element to prevent duplicates when users enter data using Flow forms.  Note that the lookup will only return one record at a time.  If, for example, your form requests four fields for a Lead: first and last name as well as an email address and company, you can use all four to match the newly input data with existing data in Salesforce.  An exact match will be returned for Pat Smith with the same company name and email address.  It will not return matches with similar company names.

In addition, if there are already two Pat Smith leads with the same company and email address, currently only one of them will be returned.  At Dreamforce 2013, there was some talk about future releases returning a collection of records.

Once you have sorted out duplicates, you can determine whether the Flow data should be used with the Create element to create a new record in Salesforce or with the Update element to modify an existing record.  Make sure your Flow users have the appropriate object permissions to perform these tasks.

Error Messages

When you connect Flow data and Salesforce data, note that Salesforce might generate errors.  For example, because Flows respect user permissions and security settings as well as required fields, a user could try to save or retrieve data that is not appropriate for them.  In these cases, Salesforce will return an error.

Use a Decision Branch to process these "Fault" behaviors after linking to Salesforce.  For example, you can present error message Screens or send a user back to a previous Screen to start over.  

Accessing Flow Variables

If you need to use it in more complex processes, Visualforce and Apex can help.  As I mentioned, Flow data is not automatically retained and is unique to the specific user's current execution of the Flow.  Variables within the Flow can be made accessible to Apex and Visualforce by changing their settings from "Private", for use only in the specific Flow, to "Input", "Output" or "Input and Output".  These settings will also determine whether a Flow variable can be accessed by other Flows when one Flow contains another existing Flow as a subflow.

Note that the only way Visualforce by itself can access Flow variables is when it sends initial values to an Input variable.  For example, if your Visualforce page calls a Flow named JustSteps, it can pass a value to start at a specific step.  The code for passing a variable to specify step 3 might look like the following on the Visualforce page:

   <apex:page>
    <flow:interview name="JustSteps">
        <apex:param name="stepNumber" value="3"/>
    </flow:interview>
   </apex:page>

The Flow would then need to incorporate a Decision element at the start to check the stepNumber Input variable.

Note that Visualforce cannot change the value of a variable after the Flow has been initiated, nor can it retrieve values from Output variables without the use of an Apex controller as well.

Apex & the Flow

You can gain even more control over Flow behavior by using an Apex controller with your Flow.  The most basic controller provides your Visualforce pages access to output variables.  For example, a simple controller might look like the following:

   public class FlowClass {
    public Flow.Interview.JustSteps myflow { get; set; }
   }

Note that the  Flow name is the same in the class and in the Visualforce page that refers to the class. 
In this case the Visualforce page that uses the controller and retrieves values for a Flow Output variable called "stepsRemaining" might look something like this:

   <apex:page controller="FlowClass">

    <flow:interview name="JustSteps" interview="{!myflow}" />
   
    <apex:outputText value="Remaining steps: {!myflow.stepsRemaining}  "/> 

   </apex:page>

Another way to get more out of your Flow is through the use of an Apex plug-in.  Note that plug-in code needs to have a particular bit of code in use in order to implement the Apex Process.Plugin Interface.  An Apex plug-in can then be incorporated like any other element directly into your Flow and can assist with more complex data processing such as creating and saving attachments or converting Leads.

Once you start delving deeply into Apex and Visualforce for use with your Flow, you will probably want to reconsider managing the process.  If your process is very code intensive, you might then decide to bypass Flow and create what you need with just Visualforce and Apex.  For those who prefer not to code any more than they have to, Flow is a great alternative.