function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
DDeanDDean 

Dynamic Form Population and Field Attributes


My apologies for the repost, but nobody seemed to have anything to say in "General Development"....


Despite the fact that we have access to the Enterprise WSDL, I've decided to use the Partner WSDL for a new project of mine. 

Basically what I've built is a dynamic form that uses an Object's Fields to populate a form on our webserver with the appropriate controls at runtime, collects the values and submits them back into SF.  I've got everything worked out the way I like: field type interpretation, field creation, list population, and even got field validation working... except that I can't think of a good way for my Salesforce Admins to indicate that a field should be required.

Take our Survey object, for example.  If they add a custom field to Surveys and make it required, then when a salesperson creates a new Survey object INSIDE Salesforce, they must supply a value.  I'm just looking for a way to indicate that it needs to be validated at the end-user.  Right now I'm using the Field's name to determine if the Field should be required by prepending "SFF_" to indicate the Field should be on the form, and not just in SF, and "VAL_" to indicate that the Field should be required. 

I'd really like to use each Field's Description property for keywords, like "Required" and "ShowOnForm" instead.  I don't like the idea of forcing a naming convention on custom Fields, and would much prefer they can modify the field more easily using it's description.  Unfortunately, I can't figure out where Object's Field's Descriptions are stored.   Apparently not as a property of the Field object itself?

Does anyone know where I can find the Description property of a custom Field?

THANKS IN ADVANCE!

PS - You're probably thinking that there are other ways to do some of this, but I've built this little framework in such a way where I can use either Salesforce or a SQL database to describe these dynamic forms and collect data, so there's a little bit of abstraction going on that might seem a little unnecessary on the surface.
werewolfwerewolf
Well I started to write a response, but it didn't sound quite right.  My best idea was to have admins create a layout and use the requiredness of fields on that layout to indicate what fields should be required in your app.  However, I'm not entirely sure that you can get to arbitrary layouts using describeLayout or the metadata API -- I suspect the best you can get is the user's current layout, and you don't want to muck with that.

Another alternative is to define a custom object which maps field names to requiredness.  That could get messy too.

So I can't really think of much more than you already have.
DDeanDDean
Thanks for thinking it over... I really do appreciate it.  It's a sticky puzzle, that's for sure. :)

As far as you know, we don't have access to the "Description" property of a custom field?  I figured that would be a perfect place, but I just can't find it anywhere.
SuperfellSuperfell
The describe results don't include the description. However they do include the required setting that exposed on custom fields. If Creatable is true and Nillable is false, the field is required. Seems like you should be able to drive your app off the real metadata in salesforce.com, no need to bundle it into random holes.
HardhatHardhat

Yes, but I took his post to mean that these fields are only required by his application, but not necessarily by Salesforce.  If he sets the fields to hard-required in Salesforce then customers will be forced to add them to their layouts and fill values for them.

Right?
DDeanDDean

Precisely. 

The order of operations on this would look something like this...

1) Salesforce Admin creates custom fields on an object.  In test case 1, the object is a "Survey", which is related to opportunities.

2) Salesperson creates a new Survey from an opportunity, such that there is a new survey instance with a unique ID.  From this they will have an url to send to a customer.  They enter no information into the survey instance themselves.  That's for the customer to fill out, via the website.

3) Customer visits my page, which reads all the custom fields of a Survey object, creates .Net controls on the page that match the custom field types the Salesforce Admin created.  Customer using the website must complete required fields.

Now the problem is, in Step 2 when the Salesperson creates a new Survey I don't want any of those fields to be required of them... they are required of the customer when they visit the website.

So I'm looking for a relatively elegant way for the Salesforce Admin to designate fields as required for the end-user, not the Salesperson.  Right now it requires the Salesforce Admin to modify the recommended name for the custom field.  So if he or she adds a field called, "Score__c", they must rename the recommended field name to "SFF_Score__c" to indicate that it should appear on the website, and then prepend that with "VAL_SFF_Score__c" to make it a required field on the website.

The Description property of each custom field would be a clean place to put keywords like, "WEBSITE" and "REQUIRED", instead of requiring someone to modify the field name.  Also consider that I'm trying to write this in such a way where I can post this code for people to implement themselves, but easily.  I have a long way to go before I have appropriate parameter cleaning and such... but taking it one step at a time.



Message Edited by DDean on 04-15-2008 10:05 PM
HardhatHardhat
OK, well if that's the scenario, and since you have control over your own app, why don't you just use the Opportunity ID and parameterize your page with it, like:

http://myapp.com/mysurvey.aspx?oppid=00600000000d3d
 
Then, when the customer submits the survey, you create the object from scratch, setting its parent opportunity per the parameter.  Then you can in fact use the requiredness of the fields without actually making the sales guy create the survey up front.  As a fringe benefit, it's two less clicks for the sales guy to get the URL -- you can stick it right up there on the opportunity, since you already know the ID of that, and you can even synthesize it in an email template so he doesn't have to copy/paste anything.


Message Edited by Hardhat on 04-15-2008 10:06 PM

Message Edited by Hardhat on 04-15-2008 10:06 PM
DDeanDDean
That is almost exactly how I did my Online RFP Wizard.

The point of this particular project, however, is not to make a form that works with our Survey object... it's to make a dynamic form system that works with ANY custom salesforce object that anyone creates, no matter what it looks like.  Then we can drop this form in on a webserver, set the object type in as a appsettings parameter, and the form just builds itself, collects data itself, and inserts into salesforce, properly, without any programming by anyone.  Then all you really have to do is skin it, and perhaps change a namespace.

The other problem is, I'd like the salesperson to be able to decide if a customer can fill out a survey, and not just through obscurity.  If I made it such that pushing surveys in actually creates an instance of a survey, you'd have to control access to the website, instead of using the existence of a survey (/custom object) in salesforce as the determining factor.

The other thought I had was that maybe I could just REQUIRE that an admin add a textarea field called "Required_Fields__c" and do a comma delimited list of required field names... but that's considerably more work, as they'd have to create another field, list all the field names manually and add them accurately.   I also briefly considered a checkbox "mate" for each required field, but that'll end up being a ridiculous number of extra custom fields and work.  

It's killing me that I've done all the hard parts... but I'm hung up on doing this part cleanly. :(
DDeanDDean
I should have mentioned, I actually wrote this in such a way where it will work the same way with a SQL table of generic design.  I can take this same form, switch from Salesforce to SQL and it does the same thing.  I'm just trying to do it cleanly on the Salesforce side so it works just as well.
HardhatHardhat
If I made it such that pushing surveys in actually creates an instance of a survey, you'd have to control access to the website, instead of using the existence of a survey (/custom object) in salesforce as the determining factor.
 
Well not really.  The existence of the opportunity would then be the determining factor.
 
If you don't want to go that route, then make a separate custom object that defines the required fields for a given object.  That would be much cleaner than trying to cram it all into the same object.
 
So what are you doing then -- trying to make a sort of generic unauthenticated portal?
DDeanDDean
So what are you doing then -- trying to make a sort of generic unauthenticated portal?

Of sorts, yes.  Its goal is that a Salesforce Admin, or Intranet Admin for a website, can create forms that collect any kind of data they want, in whatever format they want, validated or not (at their option) with virtually no programming.  It is nearly complete in this regard, except that I haven't figured out an elegant way to designate the validation and such that we're talking about within Salesforce.com's structure.

The best example I can think of is that It's really a simple version of the ability to create custom objects and fields in Salesforce, except that it renders on your website where visitors interact with it, instead of just in salesforce where only salespeople interact with it.

I expected this project to be difficult, what with the dynamic controls and translating datatypes from one place to another, but it ended up being MUCH easier than I thought, and I think people would be happy to use it, tinker with it, rewrite it, etc.

 
HardhatHardhat
Its goal is that a Salesforce Admin, or Intranet Admin for a website, can create forms that collect any kind of data they want
 
So, er...isn't that just what the Salesforce Customer Portal does?
DDeanDDean

Close, except for the featureset I'm working on and the ability to switch it back and forth from Salesforce for the design and storage environment and SQL via control panel from a company intranet.  It's biggest advantages will be its infinite cusomization.... from the control types used to interface characteristics, to datahandling on collection, etc.  When it's done I'll be happy to share so you can see for yourself how it works and what it does.



Message Edited by DDean on 04-15-2008 10:50 PM
VinodVinod

Hi,

 

I have been trying to do the same , can you tell me how did you did it or share the code.

 

 Thanks for the help.

 

 

gvk
UmapenUmapen

I have successfully implemented survey feature that collects data from sites. But I am not able to create a report of the captured results.

 

My results are comare showing like this

 

Contact a 

Question 1 - Answer1

 Question 2 - Answer2

Question 3 - Answer3

Contact b

Question 1 - Answer1

 Question 2 - Answer2

Question 3 - Answer3

 

How can I show the results as following

 

          Question1  Question2  Question 3

Con a   answer 1   Answer 2  answer 3

Con b   answer 1   answer 2  answer 3

 

Appreciate any suggestions on how I can write a wrapper class or create a SF report to show the results.