The Restricted security level does not permit any communication outside of the form template. This security level is intended to prevent harmful forms from transmitting any data from your computer to a malicious attacker. When running in this security mode, the following features will not work:

• Custom Task Pane
• Data Connections (except e-mail submit)
• ActiveX Controls
• Managed Code
• Roles
• Workflow

The Domain security level restricts a form to a particular Internet zone. The form is allowed to communicate with other data inside its own domain but is not permitted to retrieve data from other domains.

The Full Trust security level allows you to run a form with full trust on the computer where the form will be used. This security level can only be used when working with a signed form with a signature that matches a trusted root publisher on your computer or by installing the form and setting the requireFullTrust attribute to "yes". By using this setting, you can access object model calls such as file save, and you can disable certain security prompts that appear when running at a more restrictive security level.

The InfoPath designer automatically selects the appropriate security level (either Restricted or Domain) based on the features you are using in the form. The security setting is always as restrictive as possible, starting at Restricted, to ensure a greater level of protection for you and your data. Users can manually override this automated setting to select a level of security that is more appropriate for the form by doing the following:

• Select Form Options from the Tools menu.
• In the Form Options dialog box, select the Security tab.
• Deselect the Automatically determine security level check box.
• Select the desired security level.

All forms in the InfoPath designer are created with an identity. This information helps InfoPath associate forms with form templates in the cache and to retrieve updates to forms when they are posted to a shared location. By default, InfoPath creates two identities for form templates: a Form ID and an Access Path.

Form ID

The Form ID is a unique identifier based on a prefix, the form name, and the form namespace. The identifier should be a unique name that can be used to correctly associate form files with the associated form template in the client computer cache. The Form ID is specified as the name attribute in the form definition file (.xsf).

Access Path

The Access Path is a location identifier used to determine the correct location for the form template as well as a location to receive updates. When saved or published, the location to which the form template is saved or published becomes the default Access Path. Each time a form is opened on the client computer, the form attempts to associate itself with a cached form. It will attempt to do this in the following order:

1. Look for a fully trusted form template with a matching Form ID.
2. Look for a form template in the cache with a matching Access Path.
3. Look for a form template in the cache with a matching Form ID.

Once matched, the form will open with the associated form template. In cases where the match was made with an Access Path, InfoPath will use the Access Path to retrieve updates to the form template. In this way, enterprise management of forms can be simplified. In cases where the match cannot be made, the form will fail to open. The Access Path is specified as the publishUrl attribute in the form definition file (.xsf).

Just as there are two identification properties for each form template, there is a set of heuristics to specifically determine the resulting entries in the cache, based on the condition of the form template (if it has an Access Path, a Form ID, or both) and the state of the network connection.

All forms created in the InfoPath designer can be sent to users as an attachment to an e-mail message. E-mail deployment is an easy and effective way to distribute forms for interoffice use as well as to deploy forms to remote users. To mail a form template to other users, do the following while in design mode:

1. Select Send Form as Attachment from the File menu. (You will be required to save the form template at least once before doing this.)
2. Populate the To: line of the e-mail message.
3. Send the e-mail message.

Certain scenarios must be considered when building a form that will be deployed by e-mail message.

• Will your form be updated regularly? If you are developing a form that must be updated regularly, the form should be published to a shared location before it is sent to other users. This will allow you to update the form by publishing newer versions to the shared location but will also allow you to immediately distribute the form template to users who may not have access to the shared location.

  If a form is updated and then distributed by e-mail message, users will get a cache conflict message when they try to open the new form, if they have an older version stored on their computer. The user will be prompted to choose which version they want to use. Even if the updated form is the same as the one on the user's computer, the user will get a cache conflict message and be prompted to choose which copy they want to use. The best practice to use in the latter case is to share the form using a shared location instead.

• Does your form access a data connection or use other features not supported at the Restricted security level? If you are developing a form that requires Domain level security, you will need to publish it to a shared location in order for users to be able to open it. Because form templates will only open in the security level they request, forms opened directly from an e-mail message will run at the Restricted level unless they can retrieve updates from a shared location.

Forms built with InfoPath 1.0 will run in specific compatibility modes with InfoPath Service Pack 1. All InfoPath 1.0 forms will run in a compatibility mode that closely resembles InfoPath 1.0.