Lovely Systems: Lovely is hiring
Originally from Planet Plone by
Saving PloneFormGen Data Directly to Salesforce.com
For this next installment in my series of posts on integrating Plone &
Salesforce.com, we cover the tools useful for an integrator aiming to allow
those in the content editor and site administer space (albeit the more
technical ones) to integrate with Salesforce.com without
ongoing developer intervention. The first post mostly covered
the underlying technical infrastructure, while the second was of
the integrator variety and described how to display Salesforce.com data within
Plone using Zope’s templating machinery.
The Background
The more I’ve dug into and studied PloneFormGen, the more
enthusiastic I am about it as a project, concept, and code base. I think
readers of this post already likely have a lot of respect for how SteveM conducts the project, but I’m also continuously impressed with the
amount of flexibility that’s built into the code base. In this case, I’m
talking about the ability to add custom action adapters. In the NGO-space, it
really doesn’t get much more critical than allowing content editors to build
forms that collect information from would be constituents.
Someone in the Open Source Friday crew (I believe it was Brian Gershon
or Jon Baldivieso), thought up the idea of writing our own custom action
adapter for PloneFormGen that stores form data directly to Salesforce.com.
Seeing as we use Salesforce.com as a constituent relationship manager and
PloneFormGen to do things like sign constituents up for email alerts,
volunteer opportunities, and events, cutting out the extra data entry is
ideal.
In PloneFormGen’s SaveDataAdapter and FormMailerAdapter we have
a perfect example of an incredibly useful action adapter and what it would
take to create our own for PloneFormGen. In addition, we already have
Salesforce Base Connector providing a bridge, via beatbox, to Salesforce.com via its SOAP API. With these pieces in place, creating our Salesforce PFG Adapter was significantly easier.
Setting it all up
First, make sure you’re all caught up with the
setup
from the previous post (you can stop when you get to the section titled
“The Code”). Once you’ve stepped through that, it’s just a matter of
getting the dependencies needed for Salesforce PFG Adapter. These include:
- PloneFormGen
- Scriptable Fields
(bundle) - Salesforce
PFG Adapter - DataGridField – At the time of this writing, you need a particular
branch from the Archetypes subversion repository. The following within
your Products folder should do:
svn co https://svn.plone.org/svn/archetypes/MoreFieldsAndWidgets/DataGridField/branches/1.5-RC1 ./DataGridField. Hopefully, that won’t be the case in the future.
Alternately, you can grab the development bundle for testing with the following:svn co https://svn.plone.org/svn/collective/PloneFormGen/adapters/salesforcepfgadapter/bundles/ ./
Once you have all these items, restart your instance and use the quick
installer to add Salesforce PFG Adapter as shown below (this will ensure that
all dependencies are also added):
Salesforce PFG Adapter in Action
This is all hypothetical, but let’s say you run a website that encourages users to submit information about upcoming concerts featuring local artists in an effort to market regional arts. Your goal might be to display this in a calendar on your site. This alone, would not be reason enough to integrate with Salesforce.com, as we’ve already got the event content type available in Plone.
However, to add a twist, let’s say you also want to award prizes to those that submit the most events, send users annual appeals to donate to your organization, and use the events most frequently submitted to determine where you should be doing advertising for your organization. The logic of these tasks already live in your CRM. Something along these lines would be a pretty common nonprofit story and would require one to do a lot of custom programming with Plone. A better option would be to integrate your Plone site with an existing Salesforce.com application.
If you’ve got PloneFormGen, you might setup the following form (it’s a bit unrealistic, but you get the idea) for your site:
By default, you can get this emailed to you. But, that introduces the boring, error-prone manual data entry problem when you want to get this into your CRM. With Salesforce PFG Adapter and a standard Salesforce.com instance, we can take care of this data directly.
I deliberately created a more complicated example to highlight the capabilities of PloneFormGen and our Salesforce PFG Adapter, but let’s start with the basics.
First and foremost, we have 3 fields (first name, last name, and email address) that are not intended to be a part of the event object itself. Remember my use case above where I describe needing to send out annual appeals to all those submitting events, thus encouraging them to donate to your organization. We use these fields to build up our pool of engaged Salesforce.com contacts.
Using the add new item menu on our Form Folder, we add our first Salesforce PFG Adapter.
The title is unimportant. The “Salesforce Object Type” field however presents a list of eligible SObject types your Salesforce.com instance has to offer. I choose contact in my example.
From there, we hit next until we get to the “Field Mapping” section of our Salesforce PFG Adapter. This is where things get interesting. Using the DataGridField, we present a mapping-like UI for choosing which Form Fields should be associated with their corresponding SObject fields. The drop down list of SObject fields are limited to only those associated a Contact, the chosen SObject type on the first screen of the created Salesforce PFG Adapter.
The following screen shot shows how I mapped my contact-related form fields:
Next, we disable the default enabled Form Mailer Adapter and ensure that our Contact Adapter is selected.
A quick test of the form, with the following data…
… yields a new contact in Salesforce.com:
At this point, nothing is happening with the remainder of the form data. This is by design. You may choose to retrieve the rest of the form data with a different adapter. Low and behold, this is what we want to do 
After adding another Salesforce PFG Adapter to our Form Folder and providing a title, we choose the Salesforce.com “Event” SObject type:
We then provide a mapping of those form fields we want associated with the newly created Event object:
Going back to our form we now fill out the entire form with data from a fictitious user for an upcoming show I’m looking forward to attending …
In the interest of full disclosure, the Event SObject is actually one of the more complicated data types we could choose to create. We’re getting around this a bit by assuming the user will submit an appropriately formatted date/time string and an integer with the duration in minutes of the event. The real world doesn’t work like this (see “What’s Next?” below), but these are Salesforce.com Event object requirements. Additionally, to fulfill my use case where awards are given to those submitting the most events, I add a custom field “Submitted by Email” to my event type. The *right* way to do this would be to use a lookup to get the unique id of the newly created contact. This will require some additional features to be added to Salesforce PFG Adapter (again, see “What’s Next?” below).
Heading over to our Salesforce.com instance, we now have the newly created contact:
As well as the event, which is associated with the email address of the submitting user:
All this, with no manual data entry required. Bring on the user contributed content…
Why?
Hopefully, the motivations for this work are pretty clear. However, just for emphasis, I want to point out some of the reasons why I think this is pretty neat:
- It’s true — Salesforce.com already provides a utility called Web2Lead that allows for easy form creation. This, however, creates a Lead SObject, which can only be converted into a new contact, account, or opportunity within Salesforce.com. This is really great. However, you may want, as in our example, to create an SObject type (like an Event) that’s not allowed via a Lead or create multiple SObjects with one form.
- No programmers are needed for simple validation — This may be incorrect, but my understanding is that Web2Lead provides no or only simple Javascript validation of form data. With PloneFormGen, you get to choose required fields and set simple validation (i.e. is this an email address, is this a valid telephone number, is the integer between X and Y, etc.). You’re also using server side validation, which cannot be bypassed when a user disables Javascript in their browser.
- Adapters are addative – What if you want an email sent, a Salesforce object created, and the data to be saved within the ZODB. You can setup as many adapters as are needed for your form in question.
- The form is native Plone content, non-technical users can fiddle with the labels, ordering of form fields, add HTML formatted text proceeding the form, setup default values for fields, and more with the feature-set and ease-of-use offered by PloneFormGen.
What’s next?
Well, we’ve already released an experimental version for testing. Time is always short, but the goal is to crank out a steady stream of minor improvements based on issues that arise from use of the product. Because we’re integrating with a complex and powerful system in Salesforce.com, there are many both known and unknown bugs and features that are needed. Some of the known limitations include:
- We want to make sure that all of the form field data types work well with their logical Salesforce.com counterparts. For example, the date/time field doesn’t currently work with Salesforce.com, as is exposed in my demo above.
- Lookups on existing Salesforce.com will require work to get right. Again, it would have been ideal, in my example, to populate the CreatedById field on the Event to create a relationship to the newly created contact, rather than de-normalize (if that’s a word) the event by adding the submitted by email address.
- Required fields for the chosen SObject are not exposed in the Salesforce PFG Adapter UI. This requires a very deep understanding of a Salesforce.com configuration and the needed data types of fields you want populated with your PloneFormGen form.
With that said, when used in calculated cases, this is a very useful add-on Product for Plone. We’ll be putting it through its paces on ONE/Northwest over the coming months and I’m thrilled to watch and help it improve.
Saving PloneFormGen Data Directly to Salesforce.com
Originally from The Plone Blog by
from Yoda http://plonewars.com/2007/08/09/saving-ploneformgen-data-directly-to-salesforcecom/
The Plone Blog: Saving PloneFormGen Data Directly to Salesforce.com
For this next installment in my series of posts on integrating Plone &
Salesforce.com, we cover the tools useful for an integrator aiming to allow
those in the content editor and site administer space (albeit the more
technical ones) to integrate with Salesforce.com without
ongoing developer intervention. The first post mostly covered
the underlying technical infrastructure, while the second was of
the integrator variety and described how to display Salesforce.com data within
Plone using Zope’s templating machinery.
The Background
The more I’ve dug into and studied PloneFormGen, the more
enthusiastic I am about it as a project, concept, and code base. I think
readers of this post already likely have a lot of respect for how SteveM conducts the project, but I’m also continuously impressed with the
amount of flexibility that’s built into the code base. In this case, I’m
talking about the ability to add custom action adapters. In the NGO-space, it
really doesn’t get much more critical than allowing content editors to build
forms that collect information from would be constituents.
Someone in the Open Source Friday crew (I believe it was Brian Gershon
or Jon Baldivieso), thought up the idea of writing our own custom action
adapter for PloneFormGen that stores form data directly to Salesforce.com.
Seeing as we use Salesforce.com as a constituent relationship manager and
PloneFormGen to do things like sign constituents up for email alerts,
volunteer opportunities, and events, cutting out the extra data entry is
ideal.
In PloneFormGen’s SaveDataAdapter and FormMailerAdapter we have
a perfect example of an incredibly useful action adapter and what it would
take to create our own for PloneFormGen. In addition, we already have
Salesforce Base Connector providing a bridge, via beatbox, to Salesforce.com via its SOAP API. With these pieces in place, creating our Salesforce PFG Adapter was significantly easier.
Setting it all up
First, make sure you’re all caught up with the
setup
from the previous post (you can stop when you get to the section titled
“The Code”). Once you’ve stepped through that, it’s just a matter of
getting the dependencies needed for Salesforce PFG Adapter. These include:
- PloneFormGen
- Scriptable Fields
(bundle) - Salesforce
PFG Adapter - DataGridField – At the time of this writing, you need a particular
branch from the Archetypes subversion repository. The following within
your Products folder should do:
svn co https://svn.plone.org/svn/archetypes/MoreFieldsAndWidgets/DataGridField/branches/1.5-RC1 ./DataGridField. Hopefully, that won’t be the case in the future.
Alternately, you can grab the development bundle for testing with the following:svn co https://svn.plone.org/svn/collective/PloneFormGen/adapters/salesforcepfgadapter/bundles/ ./
Once you have all these items, restart your instance and use the quick
installer to add Salesforce PFG Adapter as shown below (this will ensure that
all dependencies are also added):
Salesforce PFG Adapter in Action
This is all hypothetical, but let’s say you run a website that encourages users to submit information about upcoming concerts featuring local artists in an effort to market regional arts. Your goal might be to display this in a calendar on your site. This alone, would not be reason enough to integrate with Salesforce.com, as we’ve already got the event content type available in Plone.
However, to add a twist, let’s say you also want to award prizes to those that submit the most events, send users annual appeals to donate to your organization, and use the events most frequently submitted to determine where you should be doing advertising for your organization. The logic of these tasks already live in your CRM. Something along these lines would be a pretty common nonprofit story and would require one to do a lot of custom programming with Plone. A better option would be to integrate your Plone site with an existing Salesforce.com application.
If you’ve got PloneFormGen, you might setup the following form (it’s a bit unrealistic, but you get the idea) for your site:
By default, you can get this emailed to you. But, that introduces the boring, error-prone manual data entry problem when you want to get this into your CRM. With Salesforce PFG Adapter and a standard Salesforce.com instance, we can take care of this data directly.
I deliberately created a more complicated example to highlight the capabilities of PloneFormGen and our Salesforce PFG Adapter, but let’s start with the basics.
First and foremost, we have 3 fields (first name, last name, and email address) that are not intended to be a part of the event object itself. Remember my use case above where I describe needing to send out annual appeals to all those submitting events, thus encouraging them to donate to your organization. We use these fields to build up our pool of engaged Salesforce.com contacts.
Using the add new item menu on our Form Folder, we add our first Salesforce PFG Adapter.
The title is unimportant. The “Salesforce Object Type” field however presents a list of eligible SObject types your Salesforce.com instance has to offer. I choose contact in my example.
From there, we hit next until we get to the “Field Mapping” section of our Salesforce PFG Adapter. This is where things get interesting. Using the DataGridField, we present a mapping-like UI for choosing which Form Fields should be associated with their corresponding SObject fields. The drop down list of SObject fields are limited to only those associated a Contact, the chosen SObject type on the first screen of the created Salesforce PFG Adapter.
The following screen shot shows how I mapped my contact-related form fields:
Next, we disable the default enabled Form Mailer Adapter and ensure that our Contact Adapter is selected.
A quick test of the form, with the following data…
… yields a new contact in Salesforce.com:
At this point, nothing is happening with the remainder of the form data. This is by design. You may choose to retrieve the rest of the form data with a different adapter. Low and behold, this is what we want to do
After adding another Salesforce PFG Adapter to our Form Folder and providing a title, we choose the Salesforce.com “Event” SObject type:
We then provide a mapping of those form fields we want associated with the newly created Event object:
Going back to our form we now fill out the entire form with data from a fictitious user for an upcoming show I’m looking forward to attending …
In the interest of full disclosure, the Event SObject is actually one of the more complicated data types we could choose to create. We’re getting around this a bit by assuming the user will submit an appropriately formatted date/time string and an integer with the duration in minutes of the event. The real world doesn’t work like this (see “What’s Next?” below), but these are Salesforce.com Event object requirements. Additionally, to fulfill my use case where awards are given to those submitting the most events, I add a custom field “Submitted by Email” to my event type. The *right* way to do this would be to use a lookup to get the unique id of the newly created contact. This will require some additional features to be added to Salesforce PFG Adapter (again, see “What’s Next?” below).
Heading over to our Salesforce.com instance, we now have the newly created contact:
As well as the event, which is associated with the email address of the submitting user:
All this, with no manual data entry required. Bring on the user contributed content…
Why?
Hopefully, the motivations for this work are pretty clear. However, just for emphasis, I want to point out some of the reasons why I think this is pretty neat:
- It’s true — Salesforce.com already provides a utility called Web2Lead that allows for easy form creation. This, however, creates a Lead SObject, which can only be converted into a new contact, account, or opportunity within Salesforce.com. This is really great. However, you may want, as in our example, to create an SObject type (like an Event) that’s not allowed via a Lead or create multiple SObjects with one form.
- No programmers are needed for simple validation — This may be incorrect, but my understanding is that Web2Lead provides no or only simple Javascript validation of form data. With PloneFormGen, you get to choose required fields and set simple validation (i.e. is this an email address, is this a valid telephone number, is the integer between X and Y, etc.). You’re also using server side validation, which cannot be bypassed when a user disables Javascript in their browser.
- Adapters are addative – What if you want an email sent, a Salesforce object created, and the data to be saved within the ZODB. You can setup as many adapters as are needed for your form in question.
- The form is native Plone content, non-technical users can fiddle with the labels, ordering of form fields, add HTML formatted text proceeding the form, setup default values for fields, and more with the feature-set and ease-of-use offered by PloneFormGen.
What’s next?
Well, we’ve already released an experimental version for testing. Time is always short, but the goal is to crank out a steady stream of minor improvements based on issues that arise from use of the product. Because we’re integrating with a complex and powerful system in Salesforce.com, there are many both known and unknown bugs and features that are needed. Some of the known limitations include:
- We want to make sure that all of the form field data types work well with their logical Salesforce.com counterparts. For example, the date/time field doesn’t currently work with Salesforce.com, as is exposed in my demo above.
- Lookups on existing Salesforce.com will require work to get right. Again, it would have been ideal, in my example, to populate the CreatedById field on the Event to create a relationship to the newly created contact, rather than de-normalize (if that’s a word) the event by adding the submitted by email address.
- Required fields for the chosen SObject are not exposed in the Salesforce PFG Adapter UI. This requires a very deep understanding of a Salesforce.com configuration and the needed data types of fields you want populated with your PloneFormGen form.
With that said, when used in calculated cases, this is a very useful add-on Product for Plone. We’ll be putting it through its paces on ONE/Northwest over the coming months and I’m thrilled to watch and help it improve.
The Plone Blog: Saving PloneFormGen Data Directly to Salesforce.com
Originally from Planet Plone by
from Yoda http://plonewars.com/2007/08/09/the-plone-blog-saving-ploneformgen-data-directly-to-salesforcecom/