Hide and auto-generate 'Title' column in SP Designer workflow

I have a custom list content type, which applicants use to apply for jobs. The default 'Title' column is not required as it would make no sense to the applicant. However, I don't want to rename the site column or delete it from the site because it is used in other lists.

The 'Title' column is inherited by lists and libraries from the 'Item' content type. If you don't require it you can specify it's settings to be hidden so that it does not appear in any forms.

To Hide the Title Column:

1. Open your custom Content Type Information page and select the 'Title' column. 
2. Set the Column Settings to 'Hidden'. 

To Auto-Generate the 'Title' column Value:

Using SP Designer you can auto-populate the 'Title' column based the values of other columns in your list item using the 'Update List Item' action:

NOTE: When a user creates a new list item the 'Title' will initially be set to '(no title)'.  Associated tasks in the workflow are related to the list item title by SharePoint (for example when collecting data from users). To avoid tasks being related to items with '(no title)' set a 'Pause for Duration' action for 5 minutes in the workflow to allow SP timer jobs to reflect your auto-generated title in the list.

InfoPath Forms Services best practices

This comes from: http://technet.microsoft.com/en-us/library/cc261832.aspx

Updated: 2006-12-01

We recommend that you follow these best practices when managing your InfoPath Forms Services environment.

Document limit of 2,000 in Windows SharePoint Services document libraries

If a form template will be filled out and submitted more than 2,000 times in total, you should either write code in the form template to submit to a database by using a Web service, or create a custom submit function that places forms into multiple libraries. This is due to a limitation in the capacity of Windows SharePoint Services 3.0 document libraries, which may experience performance degradation if more than 2,000 documents exist in the library.

If you think a form template may be submitted more than 2,000 times, it is easier to begin by programming the form to use an alternative submit method than to correct this issue once it becomes a problem, particularly if the form template is available to a publicly accessible Web site.

Use Form View when configuring session state for InfoPath Forms Services

You can configure InfoPath Forms Services to use the Session State Service (the default option) or Form View to control how user sessions are managed. When you configure InfoPath Forms Services to use the Session State Service, all browser sessions are maintained on the SQL Server database corresponding with the Shared Services Provider (SSP) associated with the Web application on which the form template is hosted. This scenario uses little network bandwidth, but has a cumulative performance impact on the computer running SQL Server. When you are using Form View, sessions are maintained on the client browser, and all session data is included in each postback to the server, up to 40 kilobytes of session data. This uses more bandwidth than using session state, but does not affect the computer running SQL Server. Once session data reaches 40 KB in size, the session automatically transitions to session-state management.

We recommend the use of Form View in environments that have smaller groups of users, because it reduces the impact on SQL Server. If your InfoPath Forms Services deployment will have many users, particularly if session data is below 40 KB for many high-usage form templates, session state is likely a better choice. If Form View is used, the bandwidth used by browser sessions of 40 KB or fewer can be monitored if there is a concern that network performance might be adversely affected.

Running SQL Server on a front-end Web server is not recommended

If you run SQL Server on an Office SharePoint Server front-end Web server (for example, in a single-server evaluation deployment), the ASP.NET cache will release system memory at a lower threshold than SQL Server, which could result in InfoPath Forms Services memory starvation.

ASP.NET employs a strategy of targeting maximum Internet Information Services (IIS) memory use of the lesser of either 800 megabytes or 60% of available physical RAM. These settings are configurable in IIS manager. ASP.NET also monitors physical RAM use, not just for the w3wp.exe process, but for the entire system. When 80% of the physical memory on the server is committed, ASP.NET begins periodically dropping the oldest and lowest priority 5% of the cache. When 85% of physical memory is committed, ASP.NET drops 50% of the cache periodically. At 90% or more, ASP.NET aggressively trims the cache and sets a low limit on the maximum number of entries, which remains in effect until ASP.NET reassesses memory pressure on the server and raises the threshold.

The memory usage threshold for SQL Server is higher by default than the ASP.NET cache. In this scenario, SQL Server never releases memory, because the ASP.NET cache will already have released memory before the SQL Server threshold is reached. This situation can lead to a condition in which the throughput of InfoPath Forms Services is reduced with a subsequent impact on performance.

To mitigate this issue, you should configure SQL Server memory limits manually when SQL Server is installed on the same computer as Office SharePoint Server. For more information on adjusting SQL Server memory settings, see the article Server Memory Options (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_config_9zfy.asp) on the Microsoft Web site.

Best practices for anonymously accessible forms

When you deploy a form to a location where it is exposed to anonymous users, such as a public SharePoint document library or an embedded form in a Web page on the Internet, ensure the integrity of your form. There are several additional steps you should take to mitigate the risk of improper form usage, Denial of Service (DoS) exploits, and potential performance issues.

• Ensure that form templates cannot be accessed by scripts or other automated processes. One way to achieve this is to force users who are submitting a form template to enter an identification code such as a short alphanumeric string displayed in an image, which cannot be "read" by a script or automated process.
  
  
• Form templates that contain sensitive information such as authentication information, server or database names, or proprietary code should never be exposed to anonymous users.
  
  
• Form templates that contain an e-mail submit data connection should not be deployed to servers that are anonymously accessible, as e-mail messages generated when the form is submitted will show "sent by anonymous user" in the Subject line.
  
  
• Form templates that contain code or functionality that can invoke processes on a server should be carefully evaluated and tested to ensure that security cannot be compromised by making the form template accessible to anonymous users.
  
  
• In order to prevent users from submitting multiple copies of a form, you might consider including code that tracks the IP address of each user who submits a form and prevents duplicate submissions from the same IP address.
  
  
• Protect the integrity of form templates by enabling protection to prevent the form template from being changed.

Submit InfoPath forms to SharePoint with unique filenames

This is a follow up to an issue that i initially encountered a couple of months ago when we first deployed an Infopath form to SharePoint. The original thread can be viewed here: SharePoint User Group UK

As Colin pointed out in his comment our approach left us open to the possibility of duplicate records since users could simultaneously open a new form and thereby taking the same last max id from the form library.

Although it appeared to users as though duplication was occuring, in reality the record is not duplicated because SharePoint asigns its own unique ID which automatically increments with each new record.

I have now updated the form as suggested by J_A_G, which also has the advantage of using no code.

This works by applying 2 rules to a hidden field on the form. Documents are assigned a unique filename based on the concat() function by concatenating fields in the form with the now() function. The rules determin whether or not the filename field is blank; if not it is not updated - without these rules each time a form is reopened and resubmitted it would be saved as a new form instance with a different filename as opposed to just updating an existing one.

Here's how to set this up:

• Add a hidden field to the form called 'fileName'
  
  
  
  
• Create a SharePoint Data Connection to set the InfoPath file name to the hidden field fileName
• Check the box 'Allow overwrite if file exists'
  
  
  
  
• Open Tools / Submit Options
  
• Select radio button 'Perform custom action using rules'
• Click the Rules button
  
  
  
  
• Add Rule 1 (filename is blank)
  
• Set condition 1: if fileName is blank
• Set action 1: set field's value fileName = concat(myfield, now())
• Set action 2: submit using a data connection: (the DC you created earlier)
  
  
  
  
• Add Rule 2 (filename is not blank)
  
• Set condition 1: if fileName is not blank
• Set action 1: submit using a data connection: (the DC you created earlier)
  
  

Data Connections in Browser Forms

This comes from the InfoPath Team Blog:

http://blogs.msdn.com/infopath/archive/2006/10/02/Data-Connections-in-Browser-Forms.aspx