Order View Integration in Salesforce De-Mystified

By Prabhu Palanisamy

One of the most common requirements from customers is to provide functionality to search and view orders within Salesforce.com. This step-by-step overview of building order view integrations should help de-mystify the process.

Step1: Building a wireframe

Like any other UI development, UX is very important. Depending on the order processing system there may be a ton of fields which represent order and order line items. There are some to key items to focus on when building a wireframe:

Sample Wireframe

Search Criteria
This is the critical component which takes the criteria provided and make the backend call. Here are a few considerations:

1. How does the user traverse to the order view page? If the user looks up from Account, then in addition to account identifier, filters like open orders, orders for the last 30 days or top 10 orders helps in query performance.
2. Use required fields for the search screen. Generic searches with no boundaries can potentially return thousands of rows. Based on the user profile enforcing mandatory fields is key.
3. Persisting in the order header elements and callout to backend service if we want to know more about the order.

Focus on the field elements to display.
The following questions will help in clarifying the user requirements:

1. How are the Order headers to be displayed? Layout of the Order Header?
2. Do we want to display Account level info along with Order Header?
3. Associations/Relationships with other objects Accounts, Products etc.  - Do we need to display them as read only or as look ups?
4. Field formatting - Should there be standardization and localization of the field display?
5. How does the user drill down from Order header to Order details? Should links be provided from header view to navigate more detailed views?

Page Navigation
Something to ask is whether the customer wants to list the records and paginate between result sets.

Step 2: Service definition

Having a middleware helps a lot as this can reduce the complexity of mapping and service invocation from Salesforce. Instead of being just a passthrough i.e simply acting as a broker, middleware could abstract the backend API signatures and expose only field elements required for Salesforce. This makes implementation and maintenance relatively easier.

Performance is king
The service performance makes big difference in user experience. Ideally keeping the performance in 5-10 secs improves the usability. Enforcing strict transaction timeout helps in throwing meaningful error messages back to user before Salesforce times out the request.

Pagination
Implementing a pagination at the service level helps to put a limit on the number of records returned. The input signature could include page number and page size (number of records per page). Also, in addition to the page result, the output could return query count (total number of records for the search criteria).

Data Structure
Simplifying the data results helps in UI rendering. Standard applications like SAP and Manhattan have complex nested schemas. Parsing the response in Salesforce makes for complex apex development. Middleware could provide the solution with a simplified canonical model.

Step 3: Backend

This is the most important step of all, engaging a Subject Matter Expert (SME) who has in-depth understanding of the system helps in building the proper backend service. e.g SAP ABAP developer to develop custom RFC to fetch order details.

 A few important factors to consider:

1. Explaining the requirements clearly to the backend developer.
2. Review the mapping fields, search criterias and result sets.
3. Performance and Service Level Agreement (SLA) for the backend call
4. Security, data encryption and other compliance requirements.

Step 4:

Depending on the level UI requirements, we could implement using the following ways:

1. VF custom development and render the data returned from the webservice call. In this model out of the box VF features are used.
2. Use of JQuery or other JS frameworks. In this model, the data response is returned directly to JS framework and allowing to render the data. This method helps if the service provide supports JSON formats to return the data.

Step 5: Testing and Tuning

Three areas have to be unit tested thoroughly:

1. The backend services
2. Service exposed from middleware
3. Apex classes which invokes the middleware service

Use of tools like SOAP UI can be extremely helpful in testing the services and perform proper test coverage to webservices.

Use of Canvas API:
Instead of custom VF development, one way to provide mashup functionality is to explore the use of canvas API. This allows to have external web pages to be served with Salesforce.com. The Force.com Canvas is a set of tools and JavaScript APIs that you can use to expose an application as a canvas app. This means you can take your new or existing applications and make them available to your users as part of their Salesforce experience.

Caution: This is a brand new feature and still in pilot program but provides promising features to avoid any custom development.

Conclusion:

Many times, order view is the start of the many more integrations to get a 360 view of the customer. Order view could be followed by billings, shipments, invoices, Returns etc. Having a well defined integration pattern and reusable services will help in reducing the development costs of future projects.

Cloud Metrics Launches on AppExchange

by Naoki Tsukamoto (@nikes63)

Source: www.ebbinteractive.com

We are excited to announce that after being run hundreds of times, Appirio Cloud Metrics is now available on Salesforce.com’s AppExchange!  Since its debut at Dreamforce 2012, Appirio’s Cloud Metrics has already made a great impact on companies ranging from lean start-ups to global multi-nationals with multiple orgs.  Cloud Metrics is a FREE one time snapshot report of key metrics from your Salesforce org that helps you easily identify areas such as Configuration, Code, Administration, and User Adoption that may need optimization.

Cloud Metrics has become an indispensable tool for Salesforce Administrators and Architects who want a better level of awareness about what is in their Salesforce environment, especially those that have: 

• recently inherited a new org
• managed the same org for years
• become responsible for multiple orgs across multiple countries

How does this help an Administrator manage his or her Salesforce org?  As described in the Cloud Metrics for Everyone blog, Cloud Metrics has provided insights to solve suspected problems such as:

• Need for stricter governance and change control processes - Benchmarks helped convince reluctant business stakeholders that their change requests were far above the norm.  This led to discussions on how to keep limited resources focused on the highest priorities.
• Excessive testing and support with each new release - High levels of custom code with low validation and workflow rules, triggered a discussion about opportunities to reduce custom code with configuration options.
• High maintenance effort required for every profile related change - Report indicated a large number of profiles but no permission sets which led to consultation of how to better leverage permission sets. 

You may identify with some of these challenges or may have a different set of challenges.  You may even share some of these challenges, but can justify the decision for heavy custom code to meet unique business needs or accelerate user adoption.  The point of Cloud Metrics is not that there is a right and wrong set of metrics for your org, but to promote the need to measure in order to improve your org.  It’s like when I get on the scale every morning, I have to keep telling myself a quote from management consultant Peter Drucker, “what’s measured, improves.”  Or more topically, as Phil Wainwright captured in this blog, it’s about tallying the technical debt in your Salesforce org before you lose the agility you love so much.  The act of measuring will start a conversation which will lead to insight and opportunities to improve your org. 

But don’t take our word for it - run Cloud Metrics today and let us know how it helps you manage your Salesforce org more effectively by leaving comments on this blog post or posting a review on AppExchange.

Workday Integrations Made Easy Part 1: No Complex SQLs

By Vikas Wadhwani

In a typical implementation, there can be as many as 60-70 integrations to and from other systems, e.g, integrations to talent management, real estate partner, benefits partners, EEO reporting, LMS and many more. In a legacy platform, building this would have required significant effort, but fortunately Workday it is far simpler. What was so challenging about integrating with on-premise systems?

In legacy ERP systems a developer would typicallyhave to write complex sqls to retrieve data out of a database, transform that data based on consumer requirement and then create an output file. Writing SQLs on a product database to extract data is a complex task because it requires that a developer understand usage of tables, columns, primary key, foreign key, stored procedures, functions, and more. ERP systems are complex and so are their databases. Since integrations have dependencies on databases, it requires that developers must to do an impact analysis of integration before every upgrade, ouch! So, how has Workday made integrations easier?

Workday has come up with the idea of Data source (collection of related objects) and objects (collection of sub-objects and fields). Data source is typically self explanatory as long as business meaning of common terms like Employee, Contingent Worker, Title, Payroll, Base pay, Allowance, Bonus, LOA is understood.

In order to build an outbound integration in Workday you need to create a custom report based on the Data source object. You can access objects like Worker, Payroll, Allowances, Benefits on this custom report. You will also be able to access fields within these objects on the report, for example, the Worker object will have fields like First name, Hire date, Marital status, Home address, and more. You can also add filter criteria to your report based on these fields and object, for example, (Worker type = Employee and Hire Date more than 01/01/2013).

You also have the capability to filter data on user input, for example, a user might want to provide employee status as input to a report and would like to see only employees with the status provided. Once you have built the report, you can run it immediately, as well as, add temporary filters on any field to limit the data displayed on your browser. The screenshot below shows how the Data source, object, fields and filters can be accessed on a report. Once you are done with the report, you can transform it to an output file or make the report as a service (RAAS) and you are done with building your integration.

To conclude, here are few benefits of building a integration in Workday over legacy systems.

• To extract data out of Workday you do not need to connect to a database. All the data is already available to you in Workday tenant via Data source.
• You do not need to write complex SQLs on database tables extract desired data, instead you need to write custom report and access user friendly objects and fields to access data. You don’t have to be a SQL developer to build custom report in Workday.
• You do not need to write complex joins and filter clauses to get to desired result, instead in Workday, related objects are pre-linked and you can add filter criteria on your custom report in a user friendly manner.

Stay tuned for part 2 and 3 of this blog where I am going to write about “No more object oriented programming” and “How writing webservice is a breeze in Workday”

Enabling State & Country as Picklists in Salesforce – Part 3

By Matt Lamb (@SFDCMatt)

Source: crzisme.deviantart.com

The third post in this series will explore in detail what happens when you activate the state and country and picklists, so you can better understand what changes you need to plan for ahead of time in your customization and any relevant integrations. We’ll actually tackle this in reverse, first looking at exactly what happens to your org when you activate the feature.

When the feature is activated, the existing data in the existing State and Country fields, such as BillingCountry on the Account, or MailingState on the Contact, are turned into Read Only fields. They retain their API names (e.g. BillingCountry), but when viewed through the interface they will have the words “(text only)” appended to them. Immediately after activation, these fields will have a copy of all your data prior to the mapping process.

New fields are added to your org to store the standardized picklist values. These fields will have the same name as the original fields, followed by “Code”. So if you want to query the Billing State picklist on the Account, you’d include BillingStateCode in your query. When viewed through the UI, these fields will render as picklists, and display the full text name of the standardized values.

This screenshot demonstrates a Contact record that, prior to the conversion, had the value “CA” in the ‘Mailing State/Province’ field. As you can see, that value is represented in the ‘Mailing State/Province (text only)’ field, while the ‘Mailing State/Country’ shows the standardize value for “California”.

Example record immediately after activating the feature

Going forward, the “text only” fields will always maintain a text copy of what is selected in their corresponding picklist field. For example, if we changed the ‘Mailing State/Province’ of our example record from California to Florida, the record would look like the screenshot below. This is very helpful because it means you won’t have to refactor your reports or page layouts. Anywhere where you used to display, for example, the Mailing State/Province field will still have that field, and it will now be named Mailing State/Province (text only).


The relationship between these fields is important to understand when you start to look at what changes to your code and configurations are necessary. When thinking about accessing the data in these fields programmatically, now when you query BillingCountry, for example, you’re returned the text value for that country. This is the Integration Value that was mentioned in the first post in this series. If you were to query BillingCountryCode, you’ll get the 2-digit ISO code, such as “TX” for “Texas”, or “US” for “United States”. So if left untouched, any code you had that was querying the state and country fields prior to activating this feature will continue to function, but will receive the text value of the selected state or country. If you need to get the ISO Code, you’ll need to alter your queries to point to the relevant “Code” field.

Considering the case of updating data in these fields, prior to activating this features, any updates you were making to states and countries were done so via the BillingState / MailingCountry / etc standard fields. And if you remember from a few paragraphs ago, those fields are now read-only. This is where the real effort could potentially come in. If you have any code / integrations / workflows that need to make updates to states and countries, they must be altered so they update the corresponding “Code” fields instead. And to complicate things just a bit more, as of the current release, the “Code” fields only accept ISO Codes when making updates. So if you need to programmatically update the Billing Country value on an Account to be “Sweden”, you must update Account.BillingCountryCode to be “SE”. There are a couple of ideas on the IdeaExchange you can vote for that are aimed at providing more robust functionality in this regard:

• https://success.salesforce.com/ideaView?id=08730000000keCJAAY

• https://success.salesforce.com/ideaView?id=08730000000keCOAAY

Now that you know exactly how the new fields function, it’s time to get down to the work of updating your code... but where to start? Thankfully, in addition to the data scan, Salesforce has provided a metadata scan which will produce a report of all the places in your org where the original fields were referenced. This is a great starting point to determine where you’ll need to focus your efforts and rework your code. This is the scan that was mentioned in the last paragraph of the first post in this series, and can be accessed in the State and Country Picklists menu under Data Management

While the State and Country as Picklists new feature provides a lot of value in standardizing these fields, the amount of effort to fully implement this feature should not be underestimated. You’ll want to activate this feature first in a sandbox where you can update all the necessary parts of your implementation before proceeding with enabling it in Production. To recap, the three steps are:

1. Enable and (optionally) configure the feature in your org
2. Map all your existing data to the new standardized values
3. Refactor existing customizations and integrations

When those steps are finished, you can activate the picklists and rejoice in your newly cleaned and protected state and country data! Big shout-out to Shawna Wolverton and her team for all their hard work in bringing this feature to life!

Enabling State & Country as Picklists in Salesforce - Part 2

by Matt Lamb (@SFDCMatt)

In Part 1 of this post, we outlined the process of enabling the new State and Country as Picklists feature in your org, and went over the first step of enabling and configuring the feature. This post will address the data mapping and conversion process.

Salesforce has provided an interface that allows you to select one or more values and map them to their newly standardized values. The interface shows a consolidated list of all values that show up in any of the standard State or Country fields, so you won’t have to map each object individually. First you’ll map the Countries, then the States.

As you start to work through this process, you’ll no doubt notice some data that you can’t easily map. This data likely falls into four categories, ordered from easiest to hardest to resolve:

 1. Misspelled or Variant Data 

How many users have been hand-typing these values into your system over how many years? As a result, you’re likely going to see plenty of misspellings, as well as different ways of writing the same values. Things like “UNITED KINGDOM”, “UK”, “U.K.”, “Great Britain”, etc. These should all be straightforward enough to map.

• The algorithm that matches existing data to the standardized values is case sensitive, so UNITED KINGDOM will show up in your list of things to be mapped, even though United Kingdom is the standardized picklist value.
• You can vote on the IdeaExchange (https://success.salesforce.com/ideaView?id=08730000000kdPlAAI) if you’d like to have that matching be case insensitive.

2. ISO Codes 

If you have ISO code values stored in your State and Country picklists, you’ve got a leg up to some degree. Although you’ll probably have a challenge knowing what all those values are. Quick, what’s the 2-digit code for South Africa? Of course it’s NZ. I spent quite a bit of time on this page (http://www.iso.org/iso/country_codes/iso_3166_code_lists/country_names_and_code_elements.htm) when mapping ISO codes.

3. Junk or Misspelled Data 

Someone accidentally entered a zip code or an email address into the State or Country field, or goofed and typed in Chian instead of China. If the value is relatively unique, like an email address, it’s easiest to use the Global Search feature to locate the offending record and find the correct State/Country data. In the event that the value is more common, like a zip code, use the Reporting tool to look for the particular field that contains the value you’re looking for.

4. States entered as Countries 

This could step from user error, but can also be due to geopolitical changes over time, especially if you are converting an older data set. Items such as Puerto Rico could appear in your older data set as a Country, though the standardized values provided in Spring ’13 have Puerto Rico as a State tied to the Country of United States.

• Currently there is no way to map a value in a Country field into the corresponding State field in the interface, so you should consider adjusting this data outside of the conversion interface, using on the numerous data loading clients like Apex Data Loader or Jitterbit.
• You can also vote on the IdeaExchange (https://success.salesforce.com/ideaView?id=08730000000kdQyAAI) for Salesforce to develop a more elegant solution to this problem

The State mapping process uses the same basic interface, and functions in the same manner.

The biggest thing to note about the state conversion process is that since the Spring ’13 release only contains states for the United States and Canada. This means that if you have critical state values stored currently for another country, such as Brazil, you will not be able to map those values to a standardized picklist value, thus the values will not be maintained.

All values must be mapped in order to activate the feature. At any point during your data conversion process, if you’d like to update the conversion interface to account for actions such as editing records manually to correct some junk data, you can always run the scans again, which will update the list of values to be mapped in the conversion interface.

Once you have all your values mapped, you’re half way toward enabling this feature! Catch Part 3 of this post to understand the ins and outs of what happens when you turn the picklists on, so you can better understand what you need to change about your existing customizations.

Enabling State & Country as Picklists in Salesforce - Part 1

by Matt Lamb (@SFDCMatt)

If you’ve ever put address data into Salesforce, you’ve no doubt noticed that you’ve had to type out the State and Country of your addresses. And if you’ve followed the Salesforce Community for any time at all, you’ve probably noticed that the second most popular idea of all time on the IdeaExchange is to turn State and Country into Picklists. Well you’re in luck! As they do so well, Salesforce has listened to the feedback and has developed a feature to allow you to turn the standard State and Country fields in your org, on standard objects, into picklists.

Having recently gone through this process at one of our clients, we thought it prudent to share what we’ve learned so far. Enabling the feature actually takes four independent actions, of which this post will address the first:

1. Enable and (optionally) configure the feature in your org
2. Map all your existing data to the new standardized values
3. Refactor existing customizations and integrations
4. Activate the picklists

The first step is simple. This feature is in a generally available pilot for the Spring ’13 release, and can be enabled in your org by logging a case with Salesforce Support. Once the feature is enabled, you’ll see a new area of the Setup menu under Data Management where you can access the conversion features.


If you want to disable some of the states or countries, or have existing integrations that cannot be refactored to use the new standardized values, you’ll need to configure the lists of values to be contained in the two picklists. For the Spring ’13 release, this needs to be done with the Metadata API, and the easiest way to do so is by using workbench.developerforce.com.

Start by saving this package.xml file to your desktop. Go to workbench.developerforce.com and log in to the org (preferably a sandbox first!) you want to update. Once logged in, go to Migration menu and select Retrieve. Choose the package.xml file, select Single Package.



Click Next, and on the page that follows (not shown) click Retrieve to retrieve the configuration file from the Metadata API. When your retrieve is finished, download the .zip file to your desktop using the link shown below.

Within the .zip file you’ll find the package.xml, as well as a settings folder containing a file called Address.settings. This file contains the XML that defines the state and country picklists. 

Open this file in a text editor on your local machine. You should see something that looks like this:


As of the Spring ’13 pilot release, custom states and countries cannot be added, and you cannot change the names (the Label tags in the xml) of the states and countries that are provided. The two things you can modify at this point are:

1. If you do not want a particular state or country to show up in the picklist, you can set that one to <active>false</active>
2. If you need to change the integration value of a particular entry, to comply with an existing integration with another system which cannot be refactored, you can set this value found in the <integrationValue> tag.

As an example, if you did not want to show Andorra in your country picklist, and you had an external system that was expecting UAE to identify the country of United Arab Emirates, you would update your file as follows:


Again, if neither of things apply to you, you can skip this step entirely. When you are finished, save this file. Then select the setting folder along with the original package.xml (the same two files that were included in the retrieve), and save those to a .zip file. Go back to workbench, and this time choose Deploy from the Migration menu. Choose your .zip file, and select Single Package.


Click Next, and on the following page (not shown) click Deploy. When the deploy is finished you will receive a confirmation message, and this part of the process is finished.

The next step is to run a scan of your org to analyze your data and metadata for potential impacts. The option is available within the setup area for State and Country Picklists. After the scans are complete, you’ll receive an email with links to the results. Now you’re able to start the process of mapping your existing data to the new standardized values, which we’ll cover in the next post.

Getting to Know Flow: A Hidden Gem for Salesforce Admins

Source: en.wikipedia.org

By Jeff Grosse (@CRMFYI), salesforce consultant

I’m beginning to think that one of the least explored sections of the Salesforce Setup menu is the section labeled “Flow”. The more I talk to people about it, the more I get curious responses saying, “I know it’s out there, but I have never tried it.” Flow is a somewhat hidden gem in the administrator and developer’s tool belt. The time to check out how it could be relevant to your organization is not when you find spare time; the time is now.

Flow, also known as Visual Flow, is a tool for collecting, processing and updating information in Salesforce based on business processes. It can be used in the standard Salesforce app your users are familiar with or deployed to a Salesforce portal or public website. If you’ve ever drawn a business process in a tool like Visio, designing it in Flow is very similar. It is easy enough that you don’t have to be a developer to use it, but it has the capability to use code if you want to expand your Flow to other apps or even reuse Apex code already available in Salesforce.

As a “business problem solver”, I bring my own sense of experience, expertise, and understanding to each project I work on. One of the beautiful things I like about being a consultant and working with many different companies, and teams is hearing how the experiences of others lead to solution ideas. It’s not like one person will ever have all the right answers, and in fact, with software development, there is always another way to do things which may just beat out the current idea and accelerate business further. Flow can do just that. It can augment or replace some standard Salesforce workflow. It can simplify processes, it can enforce business rules, and it can expand the horizons of what you thought you could do inside Salesforce. That’s why you need to check it out.

A brief history of Flow

Flow began as a way to visualize customer interactions and enable better decision management support for businesses. Since processes have a natural business flow to them, a team of software developers from the UK got together to improve the way those interactions take place. This team formed a company called Informavores which would be later acquired by Salesforce in late 2009. By bridging the gaps between various systems with a visual process diagram and allow process to change data in those systems, business integrations could not only be shown on paper, they could be measured by how often individual process paths were used provide facts gain insight to business. While Flow used to require a separate desktop app to design a Flow, you can now do it natively in your browser. While Flow used to look a bit different than “standard Salesforce”, it can now look like what your users are already familiar with in Salesforce or even be embedded in a Visualforce page for a completely custom look.

What can Flow do?

To understand what Flow can do both for Salesforce users and for customers, it is important to understand a few of the components of Flow.

• Screen - You can create screens to present or gather data which are, in essence, the steps to your process
• Decision - These are branches of your Flow that use data inputs and business logic to move the user to the next logical step in the process
• Assignment - Depending on input and business processes, data variables may need to be set or reset and assignments ensure the right data is stored to support the business process
• Data - At various times in a business process, you may need to look for a record or value in Salesforce. You may also need to create, update, or potentially even delete a record in Salesforce and that’s when you need the Data component.
• Apex - You can access any Apex code used by other processes in Salesforce or create new code specific to your Flow
• Flow - Reuse standard flows inside much more complex ones. Any flow can be saved and referenced inside other flows so you don’t have to recreate your past work to make use of it

What I did with it

The reason for my recent interest in Flow had to do with a customer project that I was on. We needed to guide sales reps to creating the right kind of activity records in Salesforce based on what type of event it was, the significance of that event, when it was done, and if other people were involved in that event. The answer to some of those questions would determine whether a standard Salesforce Task or a custom object record called a Call Plan would need to be created. Also from that, we needed to guide the user to the right status, target date and completed date for the activity. Finally, we needed to ensure that any activity logged was associated to a Contact from that specific Account. Here is what we did.

We used a new custom button from the Account record to begin the Flow. That button passed in the Account ID and Account Name which were stored as variables in the Flow. Using that Account ID, our Contact picklist was populated only with Contacts from the Account from which we launched the Flow. (That feature is called a Dynamic Lookup) We also used a radio button selector to know if the activity was in the Past or if it was for the Future. Lastly, we used a picklist to determine the Type of activity we were recording.

Based on responses, we determined which route the user would follow and whether a Task or a Call Plan would be created. Then we asked for either the Target Date or Completed Date for the activity based on their previous responses. Using Assignments, we then set the Status for the record we’d later create. If the result of the activity was a Call Plan, we’d show them four or five fields that were optional to fill out. (Future Call Plans had four optional fields and Past Call Plans had 5 fields, but one, called “Call Result” was required)

With all the data provided, the Flow then goes to Salesforce and creates a new record. The final page the user sees tells them that the Call Plan or Task has been created and we present them with two URLs. We present one of them if they want to go to the Account from which they originally invoked the Flow from, and we present them a second one which they can go to either the Call Plan or the Task which they just created in the Flow. Different circumstances may mean that they want to go to one over the other so we give them a choice.

The bottom line is, I created a simple process, kicked off by one click, that guided the user through creating the right record, with the right values, and helped them land where they want to when the Flow is over. We reduced the need to think about what type of record to create. We didn’t write code, yet we made the experience match the process.

If you are now thinking about what you could do with Flow, that’s awesome. If you want a process to consider trying out Flow with, I’ve got a great one. Use Flow to simplify the internal Salesforce support case creation process. Your users don’t necessarily need to see all the fields of cases when they tell you they have a problem. Use Flow to intake these questions and issues using just the fields they need. Let them kick it off with just a button or a link. It’s a great place to start.