Publishing a Project

Publish options allow SmartIQ administrators to control some key aspects of how the project behaves in Produce.

Publish options are configured when a project is first published and can be updated by visiting the publish options (Manage>Folders>’Your Folder’>’Your Project’>Publish Options)

Each publish option is described in the table below:

Option	Description	Default
Allow Preview	Turns the Preview Button on or off. When the project is being used in Produce.	Off
Allow Restart After Submission	When the option is ‘On’ and it is not a workflow submission, there is a new ‘Restart’ link on the finish page. This starts a new form with the same values as the last time you generated it.	Off
Allow Save	Allows users to save their answers on a form.	On
Auto-create In Progress Forms	Determines whether the form should be automatically saved before a user manually saves, otherwise it is discarded on exit. In a workflow project, this setting will save an in progress form (but will not create escalations or a workflow entry) before a user manually clicks save. Once workflow has been created (or a user has manually clicked save), the form is automatically saved regardless of this setting.	On
Form Interaction Log	Enables data collection for individual projects. This data contains detailed and accurate data for individual projects and page activities. This data can be viewed and downloaded under Reports in Manage.	On
Enforce Validation	When enabled a user cannot finish the web form if there are questions with outstanding validations.	On
Update Document Fields	Update the word document fields after the content has been generated. For example update the table of contents.	On
Hide Navigation Pane	Will hide the navigation pane (sometimes called progress menu) within the web form. This is useful when end users should answer the questions in only the correct order and not skip ahead and when there are only minimal pages to display	Off
Show Form Activity	Its main purpose is to display the status of workflow forms as they transition between states. The Form Activity tab is displayed in Produce.	On
Match project version when loading in progress forms	This allows control over how a project loads when it is loading from an existing workflow, answer file or save in progress. If this flag is turned on, the form will use the same version that was used when the workflow/answer file/ in progress for the form was initiated. See note below on the implications of this option	Off
Troubleshooting Mode Show Variables Show Invisible Datasources	Detects errors in a data source Visibility settings for Variables Visibility settings for Invisibility Datasources	Off
Show in Web Home	Shows published projects on the web page or restricts the project from the web channel.	On
Show in App Home	Shows published projects on the App or restricts the project from the App. Note: This option will be disabled if the project has a custom question and hidden if the license does not include App Users.
Allow Offline Launch	This feature if turned ‘On’ allows tasks which contain data sources to be continued while offline (mobile clients) Note: This option will be hidden if the license does not include App Users.	Off
Set as Home Page	Sets the current page as the homepage. Note: If a user has access to more than one Home Page Project, then the first home page project that would have displayed in the project list on Produce Home will be the one shown.	Off
Restrict Availability Dates	Allows you to provide a start and end date controlling the projects availability.	Off

projectGroupGuid

Once a project has been published, it is assigned a unique id. In Manage, go to the Projects section. Click on the name of the project. The id will show in the URL.

.../Manage/ProjectEdit.aspx?id=f99f9de8-3999-40a5-ad6c-8ca1d602a57f

Update Document Fields

SmartIQ provides a range of 'publish options' when you publish a project to a folder, including the Update Fields option. When you select this option, the document field codes - including tables of contents and other calculated fields - will be refreshed automatically during generation. This means that when a user opens the generated document, in any of the published formats, the document field codes are up to date.

This is useful, especially when using a Table of Contents (TOC) in documents that may have dynamic content reflected in the TOC. With update fields selected, depending on the dynamic content the TOC will be updated to reflect the true contents of the document include page number references.

For documents that don't require fields to be updated, you may wish to turn this option off. For extremely large documents, or when generating many repeating documents, you may find a performance improvement when this option is disabled.

To configure this option, publish a project in Manage and go to the Publish Options tab on the publish page and select or deselect 'Update Document Fields'.

Match Project Version

The publish option "Match project version when loading in progress forms" (commonly referred to simply as "Match project version") controls whether an existing workflow task should load the latest version of the form, or the version that existed when the task was started.

This is a relatively simple choice, but it can have complex implications - particularly when both minor and major alterations are made to a project.

The main reason for using Match Project Version is illustrated by the following example:

A workflow-enabled form is created, with 3 workflow states: "Start", "A", and "B". The process begins in the "Start" state, and proceeds to state "A", after which it goes to state "B".
Later, the workflow is adjusted - a new state "C" is added as an alternative to "B". The user's response to a new question in the "Start" state determines whether the next state will be "B" or "C".
If "Match Project Version" is enabled, any tasks that were created prior to the workflow being changed would follow the existing workflow ("Start"->"A"->"B"), while new tasks will follow the new workflow ("Start"->"A"->choice between "B" and "C").
However, if "Match Project Version" is not enabled, any tasks which were in progress and which were in state "A" may be stuck - as the "Start" state question which decides between states "B" and "C" did not exist when the user submitted their response.

One solution to the above problem is to design any changes to the workflow such that an older task always has a path forward (for example, letting the task proceed to "B" if the "Start" state question is unanswered) but this may not always be feasible. For this reason, "Match Project Version" is available - it allows the designer to make changes to projects with complex workflows without needing to consider the possible impacts on all potential existing tasks.

The downside of this, of course, is that minor changes to the project (e.g. changes to question layout or wording) will only be seen by users starting new tasks. The choice to use Match Project Version when publishing a project should balance the projected need to make small or large changes to the project, and the expected workflow lifetime. A project which is not expected to undergo significant changes, and which has a short workflow, can probably safely leave Match Project Version off - while a project which is expected to have significant changes and which has a long-running workflow, should probably have Match Project Version turned on.

Changing the setting

It is possible to change the setting for Match Project Version after the project has been published. Care should be taken here as well as the behavior can be unexpected - for example if Match Project Version was turned on after previously being off, tasks which had otherwise been using the latest version of the project as updates were released would load in the version which existed when the task was originally created, resulting in an apparent regression in the form version. Similarly, if the setting was turned off after previously being on, tasks which had been locked to their original version of the form would suddenly load in the latest version. Both of these cases may, depending on the severity of changes to the project, result in confusion or even lost data. For best results it is therefore recommended that Match Project Version be set and not adjusted once tasks are using the project.

The impact of changing the setting may be mitigated by publishing a second copy of the project with the desired Match Project Version state, and altering the security settings of the original publish such that users are not able to access it (when this occurs, existing tasks continue to work - only new tasks are prevented). This allows new tasks to use the new setting, while existing tasks use the existing setting. This method is not without complication, however: most notably, it means that any external links to the project need to be updated to point to the new publish. Any links not able to be updated, such as those sent in an email, would become stale and result in an error upon attempting to open them.