I'm looking to leverage Form Assembly in Salesforce to develop an online form. I'm a newb to both Salesforce and Form Assembly, but I'm wondering if the system supports a traditional normalized data model. Let me explain.
In a normal HTML form and database backend I would have multiple tables, but one of the main tables I'd have would be on that records the question response to a specific table. In a typical, normalized database that could like this:
Question ID | Response ID
Q0001 | R0001
Q0002 | R0001
Q0003 | R0002
A simple two column table with the first column being the question ID and the second column being the response value (and we'd have some unique key as a third column, but that's not the focus of my question).
But it seems though in Salesforce you have to have a column for each and every question on the form:
Q0001 | Q0002 | Q0003 | Q004
R0001 | R0001 | R0002 | R003
Etc, where (again) each question in the form has it's own column and the underlying rows are then the responses.
Can someone verify if the immediately above table is the case in Salesforce? Or can Salesforce and Form Assembly allow for a more, traditional, normalized table structure (as in my first example)?
It seems odd that the latter would need to be the case because it forces a change to the overall data structure whenever a question is changed/added to the form.
Any advise, guidance would be appreciated.
Thanks!
Jonathan
You can do normalization. What you are looking for is creating Custom Objects which are just tables. You can then create fields on these custom objects which are just database columns. To relate Objects you need a special field called a Lookup. There are 2 kinds of lookups. 1 is just a regular foreign key, the other is called master detail which again is just a foreign key however if the parent record is deleted it cascades and deletes any child records.
Check this out for help
https://trailhead.salesforce.com/en/content/learn/modules/data_modeling
Related
I'm currently tasked to redesign an application form where several fields will need to auto-fill based on the data from a specific field when it is entered.
Since I'm relatively new to LotusNotes, my boss hinted at me to first create a view which displays the fields to auto-fill. Which I did:
| Visitor Name | Company Name | Contact No | Date Entered |
Visitor Name is the field which will determine the data for Company Name and Contact No when it auto-fills in the form. Date Entered will see which data is the most recent and will use that. Also the field must be set as Editable to allow user to change the data if need be.
However, when trying to modify the form, I can't quite get how to link the view together with my desired field in the form.
I tried #DbLookup and created the formula
#If(VisitorName = "";"";VisitorName != ""; #DbLookup("" : "" ; "Local":"D:\LotusNotes Project\HR002a.nsf"; "Visitor View";#text(ContactName);#Text(CompanyName));"")
But it doesn't seem to work when I place it in Default Value or Input Translation. Even changing the filed to Computed doesn't seem to help as well.
What else am I missing in my formula?
You could simplyfiy your formula
#If(VisitorName != ""; #DbLookup("";#dbname;"Visitor View";#text(ContactName);2;[FailSilent]);"")
I am assuming this is a form used in the Notes clieny, not on the web. If this is a web form, you need a different approach.
You could very well use #DBLookup for that task. To improve performance, concatenate all the values into one column, perform the #DbLookup on the form, retrieving the concatenated values, then split them into separate values and populate the different fields.
You could also use Lotusscript. You want to look at the NotesView class and the NotesViewEntry class (assuming you want to build it for performance). Use the ColumnValues property of the NotesViewEntry class to read the columns in the view. Remember that the first column needs to be sorted.
Or your company could hire someone that already know Notes and Domino, and have that done in an hour. That would probably be financially a better choice than you spending hours or days on this fairly simple task. There are many of us here (me included) who could jump in and fix this for your company.
Folks:
I have recently begun working with xPages. I have a view of documents that needs to present data from other related documents in six separated columns. What I am trying is to use a Computed column that does a lookup to a view with a concatenated string. My intention was to parse this into the 6 columns of data. It isn't working and it may be silly of me to try referring to a computed column in another computed column.
Another alternative was to have the underlying view present the UNID of the other document and then do a #GetDocField on the xPages view.
So I have two questions:
1) May I programmatically refer to a Computed column in a view from another Computed column?
2) For efficiency, what would be the best way to present data like a 'join' in a view?
I appreciate your attention and help.
Cheers,
John Collis
Can you try to “go native” ? You build one view that contains both documents arranged to be in that view after each other. So you have Type1,Type2,Type1,Type2 etc.
Then use a repeat control to render a table or list “joining” the two rows.
This would save you doing tons of lookups.
Eventually you use that view as Json Rest source to do the joining in Json
I would create a Java bean that returns a list of Java objects that contain your data.
We have a set of BLC/DAC for a customization that has multiple tables with the given relationship
Table1 - T1ID (int-autoincrement), T1CD (char-substitute key)
Table2 - T2ID (int-autoincrement), T2CD (char-subsitute key), T1ID (reference to T1ID)
where the records in Table2 are unique for each given T1ID selected.
The initial design specification was for the users to select first the Table1 value, then the Table2 value (UsrTable1Value, UsrTable2Value respectively) in the data entry screens.
The users have recently asked if it's possible to combine these into one field simular to a Dimension selector so that there is one field resulting in "Table1-Table2" stored as T2ID.
My first thought was to simply create a subclassed dac with a concatenated property for T1CD-T2CD and base the substitute key off that however performance is a problem when that is done (1.6 million records). The delay is in the framwork side as it appears it processes the entire recordset when generating the concatenated substitute key.
Based on that I thought perhaps instead to simply generate a PXDimension configuration for this however I can't find any reference to make Dimension 2 rely on the value of Dimension 1.
I know i could always create a view that does this but i'd prefer to keep it within the framework if possible.
That basically brings me to two questions
1) Outside of a view, is there way to concatenate fields in the BQL so the lifting is done on the SQL and not with a calculated property?
2) Does anyone have or know of a sample of custom Dimensions where the values in level 2 depend on the value in level 1?
Any suggestions would be appreciated.
Out of the box, dimension selectors are designed to work only with Segmented Keys and won't be able to handle values from multiple tables. In theory, it can be possible to populate segment popup from different tables within a custom DimentionSelectorAttribute. However, this will additionally require to store each T1ID/T2ID pair in a separate table with some other column declared as a key (same concept used in the Sub table to store sub accounts: SubID is a key and SubCD stores values composed from multiple segments).
My personal opinion, the effort is just not worth it. Going one step further, I would check with the customer on how they expect navigation buttons (first, prev, next, last) to work with their segmented input control? If following standard Acumatica UI design with separate input created for every key field, no additional effort is needed to properly handle both data entry and navigation.
I'm looking for a way to build a table in a docusign template where the rows could be bound dynamically using the input data. For example, in the sample below the "Selected Options" is the table and the rows are dynamic user inputs :
**Selected Options**
2 bedroom
lake facing
non-smoking
Thanks
DocuSign does not support generic "tables" in the documents, so if you want to use a table it will have to be created at the document layer then uploaded into DocuSign.
One possible option is to create a the layout for a table in your document and leave spaces where the data will eventually go, then read or otherwise designate those locations on the document where the fields are, then finally you can place DocuSign tabs at those locations and that would in turn populate your table.
As Ergin says, DocuSign doesn't support dynamic creation of tables in a Document, such that the length (size) of the table will automatically vary according to how much data (i.e., how many rows) are specified. Your Create Envelope request specifies a (static) document, and you use DocuSign tabs to overlay data on top of that static document in specific locations.
That said, few options you might consider:
Create the table in your (static) document to contain the maximum number of columns/rows that it could ever possibly contain. Then, place tabs in every cell -- but in the Create Envelope request, only populate the tabs that correspond to the data the user provides. The down side of this approach would be that you could end up with a table that has several blank/empty rows, if the user doesn't specify much data.
OR
A more complex approach would be not define the Document in the Template itself, but rather, have the Create Envelope API request dynamically specify the Document, based on how much data the user provides. For example, if the table could contain between 1-3 rows, you could create 3 static documents -- the first with a one-row table, the second with a 2-row table, and the third with a 3-row table. Then, include logic in your code to determine how much data the user provides (1 row, 2 rows, or 3 rows), and specify the appropriate Document in the Create Envelope request. (Hint: you'd need to use 'Composite Templates' structure in the API request to accomplish this -- there's lots of info about that here on StackOverflow.) Biggest upside of this approach would be that the table in the document would always be the right size to exactly accommodate the user-provided data -- but obviously this approach could be challenging to implement and maintain if your document contains multiple tables and/or a large number of max potential rows in each table.
OR
Finally, in the same spirit as option #2 above -- if there's just a small number of variations of table size (for example: the table will always contain 1, 2, or 3 rows), you could simply create 3 Templates via the DocuSign web UI -- the first Template containing a Document with a one-row table, the second Template containing a Document with a 2-row table, and the third Template containing a Document with a 3-row table. Then, include logic in your code to dynamically choose the right template to use in the Create Envelope request, based upon how much data the user provides (1 row, 2 rows, or 3 rows).
I am a bit confused about terminology. In SharePoint we have a List and it consists of List columns but I have read in one of the site that this can be meta data too.
Taking an example if we have a SharePoint list and if we have a List Columns with name, Job description, age and Income, will this be termed as column, field or metadata?
If this is metadata then how can you define fields/columns/site column?
You may know that Meta Data is nothing but data about data.
In share point context Meta Data can be used as list column also. Consider any excel documents which are classified using Phase , Category, Document Type etc. So when ever you see these columns you can identify what kind of document it is.
As per my knowledge key words are nothing but taxonomy. By using these keywords you can classify the items.
Site Column is different. Site Column can be used as list column in any list. For eg. Consider the Age. In your site you are using Age column repeatedly in your lists/libraries. So instead of creating Age column in each list you can create only one site column and you can add to required list. In simple words reusable purpose.
Fields are nothing but a columns/site columns. These are related to list.
As Mihir states, the word "metadata" means "data about data". So to have metadata you need to have data. In SharePoint the most relevant example would be documents. Documents are data and you can have data (metadata) about these documents. Mihirs Excel example is an example of this.
Say, you want a document library in SharePoint and these documents have a document type chosen from a list of choices.
To achieve this you need to be able to put a document type on the documents. Since Document libraries in SharePoint is a special kind of list, you can create columns=fields on the list - and the data in these columns becomes metadata for your document.
So on the library you create a field, DocumentType, e.g. as a choice field. The field is setup with possible choices for the document type. So the list fields/columns are used to define metadata on the document(s).
When it comes to pure SP lists it becomes more difficult to talk about metadata. For what is it data about? In case of an employee I don't think you can define it as metadata, expect if you treat the physical person as "the data". However, I don't think it technical make a difference. You have your datamodel of the employees and implement it using SP lists - that's what they are there for!