4Creating Intake Forms

Intake Form Designer Topics

The following topics apply to using the Intake Form Designer to create and publish intake forms, which registered users access online to initiate transactions, such submitting a permit application.

• Using the Intake Form Designer

• Working with Sandboxes

• Working with Pages

• Working with Predefined Field Groups

• Using Predefined Field Groups

• Working with Group Boxes

• Working with Fields

• Adding Rich Text Areas

• Defining Fields Displaying a List of Values

• Displaying Form Elements Conditionally

• Adding Logic

• Adding Contextual Help to Forms

• Setting Form Options

• Mapping Form Fields to Decision Model Attributes

• Considering User Experience

• Testing Intake Forms

• Publishing Intake Forms

• Cloning Transaction Type Definitions

• Managing Transaction Type Configurations

Using the Intake Form Designer

This topic describes the purpose of the Intake Form Designer, lists the prerequisites that must be completed prior to creating a form, and introduces you to the designer interface.

To initiate a transaction within Oracle Public Sector Community Development, an intake form needs to be submitted by the citizen or registered user that captures the information required as prerequisites to initiating the process. Examples of transactions include permit applications, planning and zoning applications, and so on. With Oracle Public Sector Community Development, you use the Intake Form Designer to create application forms your citizens can access online, fill out, submit, and monitor the transaction all through the cloud.

Oracle does not deliver a predefined form for each type of transaction because for each form and for each municipality, the information required will be unique. For example, for a fence permit, the City of San Diego may require only basic information about the material to be used and the measurements. On the other hand, the City of Sacramento may require the same information as San Diego, but also require the contact information of the contractor building the fence, the exact location of the fence, the area enclosed by the fence, and so on. Each municipality has its own set of requirements, and the Intake Form Designer enables you to tailor the forms to reflect your agency's requirements.

With the Intake Form Designer, you can create unique online application forms for each transaction your municipality offers. The Intake Form Designer provides modular sets of common fields, called predefined field groups, which are ready-to-use form elements you can use like building blocks to assemble the online application form. If a predefined field group does not contain fields you require, you can add user-defined form elements (custom fields) to meet your requirements.

Once you have created, configured, and tested your form, you can publish the form for end users to access, complete, and submit for review and approval.

Note: For simplicity in this documentation, the Intake Form Designer is often referred to as “the designer,” and an intake form is often referred to as a “form.”

Completing Prerequisites

Before creating an online form, you need to:

• Create a transaction type.

  For more information on creating a transaction type, see Setting Up Permit Types.

• Set up any fees associated with the form.

  For more information on fees, see Setting Up Fee Itemsand Setting Up Fee Schedules.

Accessing the Designer

Before you can create an application form, you must first create a transaction type on the Transaction Type page.

From the Transaction Type Definition page, select the Design Form button.

Working with the Designer Interface

This example illustrates the interface of the designer when you begin creating an application form.

This example illustrates the Intake Form Designer interface. The controls in the image are described in the text surrounding the image.

Page Element	Description
Status	Indicates the status of the current design. Draft: the form is in sandbox mode, which means only the implementation team can access, view, and change the form design. Published: the form is available for testing or end users on the landing page, depending on your environment. In the development or testing environment, a published form is available for form developers and testers to access and test. In the production environment, a published form is available for end users to access. For more information on form status, see Working with Sandboxes.
Manage Sandbox	Click to access the Oracle Fusion Applications Sandboxes page where you can view the status of your sandbox and refresh your sandbox if needed. Note: The Manage Sandbox button appears only if the sandbox associated with your form layout becomes out of sync, requiring a refresh. For more information on sandboxes, see Working with Sandboxes.
Add Logic	Enables you to add programming logic scripts using the Groovy programming language. For more information on Groovy, see Adding Logic.
Preview	Enables you to preview your form to test layout, design, and data entry.
Save	Saves changes made to the form design.
Publish	Publishes the completed form design so that it can be accessed from the landing page.
Next	Takes you to the Fee Mapping page. For more information on mapping fees, see Mapping Form Fields to Decision Model Attributes.
Form Options	Click to display the Form Options dialog box where you can set options that apply to the entire form. For more information on form options, see Setting Form Options.
Elements panel	Contains lists of all pre-defined field groups and user-defined elements you can add to your form design. The Elements panel contains all of the items that you use to build an intake form.
Add Tab	Adds additional pages to your form. You navigate between the pages by using the page tab for each page.
Workspace	The area where you drag and drop form elements from the Elements panel and configure them. This is the main area used for creating and configuring your forms.
Attributes panel	Displays the available attributes that you can configure for the currently selected form element. For example, if you have a field selected, the attributes panel reads "Field Attributes,” and it contains attributes specific to fields. If you have a group box selected, the attributes panel reads "Group Box Attributes,” and it contains attributes specific to group boxes.

Viewing the Tasks for Creating Forms

This section provides the core set of tasks to complete when creating an intake form. The remaining topics in this chapter discuss the details of each task.

Step	Link
Add page tabs.	Working with Pages
Add predefined field groups.	Working with Predefined Field Groups
Modify field attributes.	Working with Fields
Add group boxes.	Working with Group Boxes
Add user-defined fields.	Working with Fields

Working with Sandboxes

This topic provides an overview of the concept of sandboxes and how they are used within the Intake Form Designer, and it describes sandbox usage and behavior.

Most modern development environments typically require several different individuals to work simultaneously on application changes while sharing the same data model and configuration starting point. The Intake Form Designer utilizes the Oracle Fusion Applications technology referred to as sandboxes to enable form developers to work on projects simultaneously, and save and test their work without affecting other developers or the production environment.

The sandbox acts as the development and test mode of your application form. During sandbox mode, the form design can be viewed only internally by application developers or business analysts. In sandbox mode you can create your form, add required form elements, add UI elements, and test your changes. When you have completed all of your design, development, and test work, you can then publish the form so it can be accessed by end users.

Note: Creating and modifying transaction types and intake forms should be completed on your development environment or your test environment. After making changes, publishing, and testing transaction types and intake forms on your development or test system, you would then migrate the new and modified definitions to your production system. Refer to the Functional Setup Manager documentation for information on migrating data from the test system to the production system, as well as Managing Transaction Type Configurations.

Types of Sandboxes

Oracle Fusion Applications provides these types of sandboxes:

• Classic sandboxes

• Unified sandboxes

Classic sandboxes are the default sandboxes that are enabled out-of-the-box and always stay enabled.

Note: To create intake forms, the unified sandboxes feature must be enabled.

For Public Sector Compliance and Regulation offerings, unified sandboxes are an opt in feature that you enable in Functional Setup Manager. It is required to have unified sandboxes on your development and/or test environment (depending on the number of pods you have licensed). Do not enable unified sandboxes on your production environment. Unified sandboxes are utilized during development and configuration work, which should not be taking place on your production environment. If the unified sandboxes feature is enabled on your production environment, it can lead to unexpected results, especially during the migration of data from a source environment to the target production environment.

For more information on sandboxes, see https://docs.oracle.com/en/cloud/saas/applications-common/19c/oaext/configuration-life-cycle.html#OAEXT1189604.

Starting a Sandbox Instance for a New Application Form

Before you can create an application form in Intake Form Designer, you must first create the transaction type. For example, for the permit service, the transaction type is a permit. When you save a permit type, the application creates a sand box instance. From that point, the transaction type and the associated form design exist within the newly created sandbox instance.

Each form your implementation team is currently developing exists within its own, separate sandbox instance.

Until you publish the form, the transaction type and the form design remain in the sandbox instance. When you publish a transaction type, the system eliminates its sandbox instance, and the form is available to users outside the sandbox.

Starting a Sandbox Instance for a Published Intake Form

After an application form has been published, you can initiate sandbox instances to make any required changes discovered after the initial publication.

To initiate a sandbox for a published form:

1. Open the transaction type for the form.

2. Select Design Form.

3. Begin making the desired changes.

4. Click Save.

   By clicking Save, the Intake Form Designer creates a new sandbox instance to store the current changes.

Viewing the Sandbox Status

You can determine if a form is in sandbox mode using the Status indicator located in the top left-hand corner of the Intake Form Designer. The Status indicator appears when you are creating the form or previewing the form. The sandbox status does not appear on the published version of the form.

Status	Description
draft	The form is in sandbox mode. All changes exist in the sandbox instance only.
published	The form is not in sandbox mode. The form is available to the runtime environment, where you can access the form from the landing page.

Caution: The draft status is not intended to be used for an extended period of time. It is a temporary mode for For example, at the end of every day your development work on a particular form layout should be published. You can prevent the published form that you are still designing from appearing on the landing page by keeping the Status value set to Preliminary and the Public User Enabled value set to Not enabled for public users. You set these values on the Transaction Type page. If an upgrade occurs while a transaction type is in draft mode, the sandbox will be deleted and all changes will be lost.

Refreshing a Sandbox

Each application form is assigned to its own sandbox. Because transaction types share underlying metadata resources, if during the development of a transaction type or intake form some of the shared metadata resources get updated by another member of the implementation team, each transaction type also using the shared metadata resources needs to be synchronized with the most recent metadata updates.

To synchronize the metadata between permits, you need to refresh the sandbox for unpublished transaction types.

You will know that your sandbox is not synchronized with the current metadata resources when you see this message when you attempt to publish the transaction type:

The application was unable to publish the permit. Click the Manage Sandbox button to access the page where you can refresh the sandbox.

To refresh a sandbox:

1. In Intake Form Designer, click Manage Sandbox.

   This takes you to the Sandboxes page in Oracle Fusion Applications.

2. On the Sandboxes page locate the sandbox for your transaction type.

   The sandbox naming convention is: <Transaction Type Code>__sb_<number of publications>.

   For example, if for a permit, the Type Code value is REMODEL, and the sandbox has been published once previously, the sandbox for that permit is named REMODEL__sb_1.

3. Click on the sandbox you need to refresh.

4. On the Sandbox Detail page review the messages related to the status of your sandbox.

   You may notice the Current Status reads Refresh needed and the following note:

   This sandbox is not synchronized with the mainline environment. You can refresh the sandbox before making any further changes.

5. On the Sandbox Detail page, click Refresh.

6. Click Yes on the prompt indicating you are about to refresh your sandbox and that you can’t make changes to the sandbox during the refresh.

   This returns you to the Sandboxes page.

7. View the Status column on the Sandboxes page, which indicates your sandbox is refreshing.

8. Click on the sandbox again to access the Sandbox Detail page to confirm your sandbox Current Status is Up to date.

   You may need to review the merge log and accept changes manually if needed.

9. Once your sandbox is refreshed, close the Sandboxes page, and return to the designer.

Managing Labels for Application Form Elements

This topic describes how to manage changes made to labels for delivered and user-defined application form elements.

When making changes to the labels for elements within your application form, you need to consider what type of element it is. Changing the label of some elements is a global change, while changing the label of other elements is a local change.

• Global: A global label change means that a change to the label affects every intake form definition using that field or element.

• Local: A local label change means that a change to the label affects only the current intake form definition where the field or element appears.

When you select a form element or field and a label change would have global effects, a warning icon appears above the Label field in the attributes panel.

When selecting an item in the workspace, if changing the label for that item has global effect on all application forms using the item, the system displays a warning icon.

Note: If you change the label of a field after a form has been published and used in the production system, keep in mind this can affect reporting and the storage of historical data. You may have multiple labels representing the same data.

Form Element	Scope of Label Change	Label Change Considerations
Predefined Elements	Global	The label of a predefined element is the heading used to describe the grouping of the fields it contains. Changing the label of a predefined element is a global change. For example, if you change the label in the Applicant predefined element used in the fence permit intake form, that change will be reflected in the Applicant predefined element used in the electrical permit intake form (and any other application form using the Applicant predefined element).
Predefined Element: Parent Field	Local	Some fields appearing in predefined form elements are part of the parent record within the data structure storing the transaction data. You know a predefined element field is part of the parent record when the warning icon does not appear above the Label field in the elements panel. For example, the Description field in the Application predefined element does not display the warning icon. Changing this label affects only the current intake form definition. It is a local change.
Predefined Element: Child Field	Global	Some fields appearing in predefined form elements are part of a child record within the data structure storing the transaction data. You know a predefined element field is part of a child record when the warning icon appears next to the Label field in the elements panel. For example, the Demolition Reason field in the Demolition predefined element displays the warning icon. Changing this label affects all intake form definitions using the Demolition predefined element. It is a global change.
User-Defined Elements	Local	You can change the labels for the fields that you add to your application forms, such as text fields, number fields, drop-down lists, and so on. Because you add these fields manually to your application form, you can change the default labels as needed to suit your business requirements. The scope of any changes to the label for user-defined fields apply only to the current intake form.
HTML Constructs	Local	A general HTML construct refers to elements such as group boxes and page tabs. You can change the labels for general HTML constructs as needed to suit your business requirements. The scope of the construct and any changes to the label apply only to the current intake form definition. For example, changing the label of the default label for HTML constructs such as Group box or Field 0 to your desired label affects only the current intake form definition. Note: If you change a label for a page tab or a group box used in an application form after the form has been published and used in the production system, make sure to update any instructions or documentation that may reference the previous label.

Note: For HTML constructs, such as pages and group boxes, and for user-defined fields the labels display using the language used to create or modify the application form layout. There is no automatic translation of these elements. For example, if you created the form in English, but then signed in using Korean for testing, you will see the English labels for those constructs, unless you have provided translated values using the Fusion Applications User Interface Text tool. For more information on the User Interface Text tool, see: User Interface Text Modification.

Working with Pages

This topic describes how to add pages to your application form and how to modify page attributes.

An application form can include one or more pages to contain the field groups and fields that you want to add to your form.

Adding Pages

When you create a form, by default, the application includes one page for your form. To add additional pages to your form, click the Add Tab button at the top of the workspace.

Setting Page Attributes

Page Element	Description
Label	The name of the page that appears on the page tab. The default name is Page 1, Page 2, and so on. Change the name to your desired label, and tab out of the field.
Hide from public user	Hides the page tab and all the elements on the page from the public user at runtime. Only agency staff can view and update information for a page with Hide from public user turned on. In addition to hiding the UI element from the public user in the interface, the application also secures the back end for that specific UI element, such as preventing any unauthorized access to the fields within the UI element using a REST API, for example. Note: An application intake form must have at least one page that is viewable to the public user. That is, Hide from public user must not be enabled for at least one page tab in the form.
Add Help	Click to launch the Contextual Help page, which you can use to add help information to aid end users in completing the application form. Page-level help should provide information pertaining to the overall page content. If the information applies to a specific UI element on the page, such as a component, group box, or field, consider adding help directly to that UI element. For more information on adding contextual help, see Adding Contextual Help to Forms.

Deleting Pages

If you delete a page from your form, keep in mind that any UI elements you have added to the page, such as predefined form elements, group boxes, and fields will also be removed from your form.

To delete a page from your form:

1. Click the Remove button on the tab (the ‘x’ on the right side of the page tab.

2. On the Confirm dialog box, click OK.

3. Save your changes.

Working with Predefined Field Groups

This topic provides an overview of predefined field groups and how you use them to build your application forms.

Oracle provides a set of predefined field groups to help you build application forms easily. Each predefined field group contains a collection of fields commonly used to capture information for a particular facet of the transaction type. For example, the Applicant field group captures information about the person applying for a permit, and the Electrical field group captures information about the scope of electrical work for a project. Using predefined field groups, you can assemble simple online application forms in a matter of minutes.

Predefined field groups are:

• Pre-mapped to attributes in the application view object (VO), which ultimately are mapped to fields in the SQL tables in the application database.

• Grouped logically to provide descriptive metadata for a particular element of an intake form, such as Applicant, Electrical Equipment, Pool Information, and so on.

You drag the desired predefined field group from the Elements panel onto the workspace. You use various combinations of predefined and user-defined form elements to assemble your application forms.

For example, assume that you need to create a form for citizens to apply for a roofing permit. In this case, you can drag the Applicant element and the Re-roof Information element onto the workspace to build your form.

Page Section	Example Page Section Fields
Applicant	Name Address Phone
Re-roof Information	Roof Size Roof Type Roof Material Pitch

For more information on the delivered predefined field groups, see Using Predefined Field Groups.

Adding Predefined Field Groups

To add a predefined field group to your form:

1. Make sure the page to which you want to add the predefined field group is the active page.

2. Expand the Ready to Use list in the Elements panel to the left of the workspace.

3. Click on the desired field group to activate it.

4. Select the field group to drag and drop it in the workspace.

This example illustrates dragging and dropping a field group onto the workspace.

Note: Intake Form Designer places the predefined field groups in the workspace in the same order in which they are dropped, in sequence, from top to bottom.

Note: The Applicant predefined field group is required to be added to your application forms. The internal save logic checks for a valid applicant address when an end user attempts to save or submit an application form. It is recommended to include also the Application Information predefined field group, which displays useful information, including the transaction ID, status, description, important dates related to the application, and so on. If the transaction type requires fees, then the Fee Summary predefined field group should also be added to your application form.

Deleting Predefined Field Groups from a Form

To delete a predefined field group, click the Remove button in the Attributes panel.

Setting Predefined Field Group Attributes

Page Element	Description
Remove	Click to remove the field group from the page.
Label	The name of the predefined field group. Initially displays an internal reference for the default label. Modify the label for your preferred label to display. Note: Changing the label for predefined field groups can cause unexpected results if you don’t consider whether the change will be local to the transaction type or global, affecting all transaction types.
Show Label	Control whether to show the label. By default, the system shows labels for predefined field groups (Show Label is on). To hide the label, turn off Show Label. When turned off, the system hides the label at both design-time and runtime. Typically, you’d want the label to be visible to describe the logical grouping of the fields in the form element. In some cases, the page tab name and the predefined field group label might be redundant, in which case you may opt to hide the label. You may also want to group multiple predefined field groups within a single group box. In this case, you can hide the individual predefined field group labels within the group box container, using the group box label to represent the combined set of fields. Note: When you turn off Show Label, the system disables the collapsible feature for a predefined field group. Note: If the predefined field group is delivered without a label, the Show Label attribute does not appear when you select that form element.
Hide From Public User	Hides the predefined field group and all the fields and controls it contains from the public user at runtime. Only agency staff can view and update information for a predefined field group with Hide From Public User turned on. In addition to hiding the UI element from the public user in the interface, the application also secures the back end for that specific UI element, such as preventing any unauthorized access to fields contained within the UI element using a REST API, for example.
Add Help	Click to launch the Contextual Help dialog box, which you can use to add help text to a predefined field group for assisting users with interacting with your intake form. When adding help for a predefined field group, the help text should apply to the overall contents of the predefined field group. You can add help also at the page level and the field level, depending on the scope of the help text. For more information on adding contextual help to your intake form, see Adding Contextual Help to Forms.
Control Display	Click to define other elements in the form to control wether the field group displays. For more information on controlling the display of form elements, see Displaying Form Elements Conditionally.

Adding a Predefined Field Group Multiple Times to the Same Form

The same predefined field group can be dragged into your form multiple times. This is referred to as a multiple-instance element. How you adjust the Multi-Instance Options attribute determines how the application stores the data for that predefined field group.

Note: The Multi-Instance Options attribute appears only for the Comments and the Attachments field groups.

If you make no changes to the Multi-Instance Options attribute, the data entered within that predefined field group corresponds to one row of data only. In this case, the system duplicates the display of the data in each area of the form it is displayed. This option enables you to show the same data on a different tab within the form, if necessary. Updating the data in one instance of the predefined field group updates the data displayed in the other instances as well.

For example, assume you want the same comment text to appear on multiple pages in your form. You can do this by adding the Comments element to the desired pages without making any updates to the Value field in the Multi-Instance Options attribute.

If you make changes to the Multi-Instance Options attribute, the application considers each instance of the predefined field group unique, and then each individual occurrence of the predefined field group is associated with its own row of data.

For example, assume you wanted to incorporate multiple comment sections in your form. In this case, you can add the Comments element to multiple locations of your form, and then you set the Multi-Instance Options attribute to different values. One might relate to fencing comments while another might relate to contractor comments. Another example would be to enable the end user to upload multiple attachments that apply to separate documents. One attachment might be photos of a property while another attachment might be blueprint or design documents.

Using the Keyboard to Drag and Drop Elements

You can use keyboard hot keys to drag and drop elements.

Key	Description
Enter	Use to: Expand or collapse the Ready to Use or Add New element lists. Drop a selected element onto the selected drop zone
Tab	Use the tab key to select either the first element in the list or the last selected item in the list if a previous visit was made to the list.
Up and Down Arrows	Use to: Select an item in the Ready to Use or Add New element lists. Select a location from the drop zone list. The selected drop zone is highlighted.
Space	When an element is selected, the space key highlights the selected element and displays available drop zones for the current page on the Select a Drop Zone dialog box. The drop zones can be the page or group boxes contained by the page. For user-defined fields, the drop zones are group boxes.

Using Predefined Field Groups

This topic lists and describes the set of predefined field groups delivered to help you build forms quickly and consistently.

Predefined field groups are prebuilt user interface modules that you can use as building blocks for assembling forms. Field groups provide a set of fields and functionality to capture information for various sections of an application form.

Common Predefined Field Groups

Field Group	Description
Applicant	Identification and contact information for the citizen filling out the form, including name, address, phone, and email.
Application	Displays information about the form itself, such as status, relevant dates, and descriptions.
Attachments	Enables you to attach and download files, such as documents or images. You determine document properties displayed in the list of attachments and during upload. Contains multiple instance options to create unique instances of the attachment field group.
Comment	Enables you to enter additional comments or descriptions pertaining to information on the form. Contains multiple instance options to create unique instances of the comments field group.
Contact Details	Enables you to add information for individuals or organizations that are contacts for an application. When users enter contact information in an application, they can create new contacts or choose existing profile contacts. When creating a new application contact, the user can indicate whether the new contact should also be added as a profile contact. When choosing an existing profile contact, the user can modify contact details and indicate whether the original profile contact record should be updated as well.
Demolition	If demolition is required as part of the job, this field group captures information related to the scope of the demolition and if hazardous materials or utilities need to be considered, such as electricity, gas, water, and so on.
Fee Summary	Lists the items selected, the cost for each item, and the total amount to be paid when submitting the form. Note: This does not include additional inspection or other fees which may be assessed at a later time.
Property	Describes the parcel as it is registered with the municipality, such as the parcel ID, parcel type, and so on.
Site and Zoning	Describes features of the property related to acreage, flood preparedness, as well as zoning and land usage information.
Terms of Use	Provides access to the terms and conditions regulating the usage of the online form, and provides a way for the user to accept the terms. This field group does not identify which Terms of Use definition to use, so if you add this field group to an application intake form, you need to also add a Terms of Use definition on the Permit Type or Planning Application Type page. The Display Mode property has these options: Link: the form displays a Terms and Conditions link that the user clicks to open a window with the full terms and the check box for accepting the terms. Embedded: the full text of the terms appears directly on the form. If the display mode is Link, these two additional properties are available: Help Text: Enter informational text that appears on the form along with the Terms and Conditions link. Display Label: Enable this option to display the description of the Terms of Use definition on the form along with the Terms and Conditions link. Note: This field group is not used to set up public user registration terms and conditions. The Public User Setup page includes all registration-related configuration.

Attachments Field Group

You can configure the attachments field group and add it into your form multiple times. Attachments provide supporting documentation needed by agency staff when processing a transaction.

Configurable Features	Description
Component Attributes	You can name the attachments component title in the Label field.
Component Multi-Instance Options	Use these multiple instance options to create unique instances of the attachment field group: ID Value For more information about multiple instance options, see Working with Predefined Field Groups.
Attachment Columns:	You can configure these attachment properties in the attachments list: File Name: Display the file name of the uploaded file. Description: Display the user-entered description. File Size: Display the size of the uploaded file.
Business Columns: DocumentCategory DocumentSubcategory	Agency-defined document categories and document subcategories enable you to organize the various types of attachments. You can configure these fields for document categories and document subcategories: Label: Change the field name. Show in List: Display the field in the attachments grid. Show in Detail: Display the field in the attachment detail information. Show in Upload: Display the field on the modal page for uploading an attachment. Searchable: Enable search on the document category or document subcategory field. Sortable: Enable sorting for the document category or document subcategory field.

Predefined Permit Field Groups

Field Group	Description
Business Information	Captures information to help describe the business, such as name, description, number of employees, industry, and so on.
Construction Information	Captures information regarding the current construction site and the proposed construction project.
Electrical Equipment	Describes a structures electrical features, such as outlet types, amps, voltage, and electric appliances.
Fence Information	Describes the proposed fence attributes, such as type, material, dimensions, location, and so on.
Grading Information	Describes the scope of grading work, such as the acreage affected, materials to be used and the amount of material.
Insurance	Provides a contractor’s insurance type and policy information.
License Qualification	Enables a contractor to add any state licences they have.
Mechanical Equipment	Describes features of the job site related to ventilation, heating, cooling, fire safety, and so on.
Photovoltaic Information	Describes attributes of a site’s solar energy configuration, such as roof area, coverage area, inverter information, and so on.
Plumbing Equipment	Describes attributes of a site’s plumbing configuration.
Pool Information	Describes attributes of a pool, such as type, depth, location, surrounding fencing, and so on.
Regulated Business Activity	Enables you to specify any regulated activity or controlled substances allowed on the premises, such as alcohol, carnival rides, casino games, and so on.
Right of Way Use	Enables you to provide any details related to the use of a right-of-way on the property or to gain access to the property, such as traffic, parking, or pedestrian impact.
Roof Information	Describes features of a structure’s roof, such as existing roof type, proposed roof type, number of layers, and so on.
Signage	Describes features of signage, such as the sign’s dimensions, use, whether permanent or temporary, and illumination.
Special Event	Enables you to specify information about an event, including the safety plan, concessions, facilities, potential impacts, and traffic plans.
Water Heater	Describes features of water heaters, such as quantity of new or replaced, type, fuel type, and tank capacity.
Yard Sale	Enables you to specify yard sale information, such as the start time, end time, and the number of days.

Predefined Planning and Zoning Field Groups

Field Groups	Description
Dwellings	Describes features of housing such as number of units, floor area information, density bonus, rent-controlled units, and so on.
Impervious Surface	Describes features of areas covered by impervious materials, such as concrete or asphalt, including exemptions from certain requirements, existing and proposed impervious surface areas, and the property lot area.
Planning	Describes features included in planning and zoning, such as proposed number of units, change to the number of units, assessed value of the current building, development type, commercial building area, existing land use, lot areas, setbacks, and so on.

Working with Group Boxes

This topic describes how to add group boxes to your form and discusses group box layout options and attributes.

Use group boxes as containers to indicate the items contained within a group box are grouped logically. Once you add a group box to a page, you can drag these items into the group box:

• Predefined field groups

• User-defined fields

• Other group boxes (nested group boxes)

Adding Group Boxes

To add a group box:

1. Open the Add New llst in the Elements panel.

2. Open the Layout list.

3. Click and hold on the Group box option.

4. Drag and drop the group box into the workspace.

Deleting Group Boxes

To delete a group box, click the Remove button in the Attributes panel.

Note: If you remove a group box from a page, the system removes all of the contents of that group box also.

Setting Group Box Attributes

Select a group box to view the Group Box Attributes panel.

This example illustrates the attributes for a group box. Details are provided in the surrounding text.

Page Element	Description
Remove	Click to remove the group box from the page.
Label	Add a name for the group box, describing the collection of items within it.
Collapsible	Turn on to enable the group box to be collapsed when an end user clicks it, hiding items it contains. If not turned on, the group box is always expanded and its items are always visible.
Flexible Box Layout	Use the Flexible Box Layout attribute to establish a group box container based on the CSS flexible box layout model. In the flexible box layout model, the items contained within the parent container assume a layout position automatically, based on space in the container. As the available unused space grows or shrinks, the items in the container grow to fill the unused space or shrink to avoid overflowing the parent. With Flexible Box Layout enabled, the system displays as many controls within the group box in one line until all of the space is utilized, then the system wraps the row, beginning a new line. When disabled, the controls within the group box display as stacked items, with each additional control displaying directly beneath the previous control.
Show Label	Select to hide the group box label (specified in the Label field). Note: You can add help only to group boxes with Show Label turned on. If Show Label is turned off, the Add Help button does not appear on the attributes panel and any help icons associated with any previously added help no longer appear.
Hide Border	Hides the group box border. When turned on, the border is not visible.
Hide from public user	Hides the group box and all the elements in the group box container from the public user at runtime. Only agency staff can view and update information within a group box with Hide from public user turned on. In addition to hiding the UI element from the public user in the interface, the application also secures the back end for that specific UI element, such as preventing any unauthorized access to the fields contained within that UI element using a REST API, for example.
Add Help	Click to launch the Contextual Help page, which you can use to add help information to aid citizens in completing the intake form. The Add Help button appears only if Show Label is turned on. Help text added for group boxes should apply to the overall group box content. Help can be added also at the page level, field group level, and field level depending on the scope of the help text. For more information on adding Contextual Help, see Adding Contextual Help to Forms.
Control Display	Click to select an element in the form that controls the display of the group box. For more information, see Displaying Form Elements Conditionally.

Example: Nesting Group Boxes

Nested group boxes can be used to represent subcategories of information and to enhance layout options, such as creating columns for form elements.

The following example illustrates nested group boxes, which you achieve by dropping group boxes within group boxes.

This example illustrates an outer group box container with two inner group boxes nested within to logically divide page content.

Note: The system does not impose a limit to the depth of nested group boxes you can insert. For more complicated pages, for example, you may find that group boxes could be nested to 4–5 levels deep. Make sure to consider how a page with multiple levels of nested group boxes will render on all the devices you intend to support for your user base.

Example: Using Group Boxes to Combine Predefined Elements

In some cases you may want to give the appearance of multiple field groups being combined. You can do this using a group box to act as the outer container for the set of field groups. When using a group box to contain field groups, consider the following items:

• The collapsible attribute of the group box container controls the visibility of the contained field groups. If the group box container is set to be collapsible, when the user collapses that group box, all of the elements within that group box will be hidden.

• If you want the field groups within the group box to be categorized under just the label of the group box, turn off the Show Label attribute of the contained field groups.

In the following example, assume you want to combine the Fence Information and Comment field groups, giving the appearance that Fence Information field group also contains a Comment field.

To combine field groups within a group box container:

1. Open the Add New list in the Elements panel.

2. Open the Layout list.

3. Drag and drop a Group box into the workspace.

4. Select the group box and make these changes on the Group Box Attributes panel:

   Group Box Attribute	Sample Value
   Label	Fence Information
   Flexible Box Layout	Off

5. Open the Ready to Use list.

6. Open the Field Groups list.

7. Drag and drop the Fence field group into the group box

8. Select the Fence field group, and turn off Show Label on the Attributes panel.

9. Drag and drop the Comment field group into the group box.

   

10. Select the Comment field group, and turn off Show Label on the Attributes panel.

11. Save your changes.

At runtime, the example steps above produce a single, collapsible section in the form that includes both the Fence Information and the Comment predefined elements.

This example illustrates the collapsed Fence Information group box.

This example illustrates the expanded Fence Information group box containing multiple field groups.

Example: Using Group Boxes to Combine Field Groups and User-Defined Fields

Similar to combining field groups within a single group box container, you can also combine field groups and user-defined fields within a single group box container creating the appearance of user-defined fields being part of a delivered field group.

In the following example, assume you need to associate a field with the Fence Information element to capture the color of a proposed fence.

To combine predefined elements and user-defined elements with group boxes:

1. Open the Add New list in the Elements panel.

2. Open the Layout list.

3. Drag and drop a group box into the workspace.

4. Select the group box and make these changes on the Group Box Attributes panel:

   Group Box Attribute	Sample Value
   Label	Fence Information
   Flexible Box Layout	Off

5. From the Ready to Use > Field Groups, drag and drop the Fence field group into the group box.

6. Select the Fence field group, and turn off Show Label on the Attributes panel.

7. From the Add New > General, drag and drop a text field into the Fence Information group box.

8. Select the text field, and enter Color for the Label in the Field Attributes panel.

   

9. Save your changes.

The following example illustrates how at runtime, the group box containing the field group and the user-defined field create the appearance of the manually created field being part of the delivered field group.

Working with Fields

This topic describes how modify field attributes and add fields to your forms.

When end users are completing an application for a transaction, such as a permit, they enter the required information in fields. Fields can be added to forms by:

• Adding predefined field groups to your form. Each field group is delivered with a set of fields.

• Adding user-defined elements (fields) to your form.

Note: The user-defined fields that you create cannot be used (shared) across multiple intake form layouts.

Setting Field Attributes

Select a field to view the Field Attributes panel. Fields in predefined field groups and user-defined fields typically have the same set of attributes. Not all attributes apply to each field type.

The type of field you select determines the attributes appearing in the Field Attributes panel. For example, for a number field, you can set a default value and a placeholder value, but for a single-item check box, neither of these attributes apply and therefore do not appear.

This example illustrates how the Field Attributes panel looks after selecting a field.

The following table describes the field attributes you can set. Note that not all attributes apply to every field type. Only the attributes that apply to the currently selected field appear.

Page Element	Description
Remove	Click to remove the selected field from the layout. The Remove button appears only for user-defined fields you added manually. You can’t remove fields from a delivered field group.
Label	Add a custom label to the field. Note: In the case of a custom field, the system forces the Map Field value to match the Label value, but removes any spaces. The map field represents how the field appears in the underlying data model. For example, a custom field with the label Additional Requests, will have a Map Field value of AdditionalRequests.
Placeholder	Add descriptive text to provide hints for entering data. For example, the placeholder text could read: Enter date in this format” MM/DD/YY. The placeholder value does not get saved at runtime.
Default Value	Enter a default value required for the field. The default value gets saved at runtime if the user does not change it. Note: In cases where both the Placeholder and Default Value attributes appear for a field type and you have provided values for both, the default value supersedes the placeholder value. That is, at runtime, the user sees the default value, not the placeholder value, but if they delete the default value, the placeholder value appears to help users enter a valid value.
Required	Enable if this is a required field for which a user must enter a value. Note: You can’t delete a field that has been set to be required. You must first turn off the Required attribute, save the form layout, and then delete the field. Deleting a required field from an intake form that has already been published may affect forms submitted previously.
Hidden	Hides the field from the user. If a predefined element contains fields that you do not need, select this option so the user does not have access to the field.
Open Additional Attributes	Add values for fields containing a list of values, such as check boxes, lists, and so on. For more information, see Defining Fields Displaying a List of Values.
Add Help	Click to launch the Contextual Help page, which you can use to add help information to aid citizens in completing the intake form. Help text added at the field level should apply specifically to that field. You can also add help to predefined elements, group boxes, and pages, depending on the scope of the help text. For more information on adding Contextual Help, see Adding Contextual Help to Forms.
Add Logic	Click to add scripting logic using the Groovy programming language. Note: For user-defined fields that you have added to your intake form manually, the Add Logic button appears only after you have saved your form. For more information on adding logic to your forms, see Adding Logic.
Edit	Click to display the Rich Text Editor dialog box for entering formatted text to the application form. Appears only for rich text areas. For more information on rich text areas, see Adding Rich Text Areas.

Adding User-Defined Fields

Note: You can add user-defined fields to group boxes only. You can’t add user-defined fields directly to a page or a delivered field group.

To add a user-defined field:

1. Expand the Add New section of the Elements panel.

2. Open the Layout list.

3. Add a group box to the current page.

4. Open the General list in the Add New section.

5. Select a field type, and drag and drop it in the desired group box.

   Note: User-defined fields must be contained by a group box.

6. Select the user-defined field you added, and use the Field Attributes panel to configure your field.

   Note: User-defined fields and fields provided in predefined field groups use the same set of attributes.

7. Save your changes.

   Once saved, the system applies your user-defined field to the application data model so field data can be captured, stored, and retrieved.

Choosing User-Defined Field Types

Expand the Add New section in the Elements panel and open the General list to view the field types you can add to your forms.

Note: You must first add a group box to your form, and then you can drop one or more user-defined field types into the group box container.

Field Type	Description
Text field	Adds a character field to hold text values. A text field is limited to a length of 200 characters. If you need to provide a field that enables users to enter more characters, consider a text area field.
Number field	Number field used to contain integer values.
Date field	Stores date values, such as 09-26-2018.
Date time field	Stores date and time values, such as 09-26-2018 11:25 AM.
Switch	On-off field, such as an “active” field indicating whether an item is active or not, which would be either on or off (yes or no).
Text area	A long character field enabling the user to enter longer descriptions. A text area field is limited to a length of 1500 characters.
Rich text area	A long character field enabling the user to enter longer descriptions or instructional information that can be formatted using a rich text editor.
Single-item check box	Displays a single option for the end user to select, such as, "I have read the terms and conditions, and I agree to the terms and conditions." This is different from a check box set, which displays a list of multiple items for an end user to select. In the case of a single-item check box, the label of the field acts as the text the end user reads and responds to on the application form.
Check box set	A set of check boxes from which the end user can make multiple selections. For example, the label for the check box set might be Heating Source(s), with values such as Oil, Gas, Wood, Solar, and so on.
Radio button set	A set of radio buttons from which the end user can make a single selection. For example, the label for the check box set might be Fence Type, with values such as Stone, Wood, Vinyl, and so on.
Drop-down List	A drop-down list allowing the user to select a single item.
Multi-select List	A drop-down list allowing the user to select multiple items.

Hiding Fields

In some cases, you may not want to display all of the fields associated with a delivered field group you've added to a form. You can hide unneeded fields so they do not appear to the user at runtime.

To hide fields:

1. Place your cursor in the field to select it.

2. Turn on the Hidden switch on the Field Attributes panel.

Once you have hidden a field, the design-time interface continues to display the field, but places a darkened background around the field to indicate it is a hidden field. The application does not display the field at runtime.

This example illustrates the shading around a field to indicate that is hidden during design time.

In this example of the design-time interface, Location and Material are not set to be hidden, but Corner Lot and Other Material are. Notice that the hidden fields display with the darkened background.

The following example of the runtime illustrates that the hidden fields do not display when an end user access the form. Only Location and Material render on the form at runtime, while Corner Lot and Other Material are not rendered.

This example illustrates the fields indicated as hidden in the previous example in design time do not appear on the form at runtime.

Note: At runtime, the system applies this style to the hidden field: style=”display: none;”. This style prevents the field from being visible on the page.

Note: Required fields can’t be hidden fields. If you set a field to be required, the Hidden switch becomes disabled. If a field is set to be hidden, and you set it to be required, the system sets the Hidden switch to off automatically and disables the Hidden switch.

Adding Rich Text Areas

This topic describes how to add rich text areas to your intake forms so that you can display formatted text in application intake forms.

Rich Text Area Overview

In some cases, you may need to add rich text areas to your application forms so that you can display formatted text for users filling out the application. For example, if you needed to provide additional information, such as instructions or reference material, you can provide that within a rich text area.

Note: The rich text area provides a way for your agency to provide read-only formatted text for end users. A rich text area does not enable the end user to be able to insert formatted text into the form.

When you add a rich text area element to your form, an Edit button appears in the Field Attributes panel when you select the rich text area element. The Edit button launches the Rich Text Editor dialog box.

This example illustrates the Rich Text Editor dialog box displaying bold, colored, and italicized text; normal text; and text within a numbered list.

The Rich Text Editor dialog box provides these formatting options:

• Font size

• Bold, italic, underline

• Copy formatting

• Text color

• Text background color

• Numbered and bulleted lists

• Undo and redo

• Increase and decrease indentation

• Horizontal line

Adding a Rich Text Area to a Form

To add a rich text area:

1. Insert a group box into your form where you want to place the rich text area.

2. From the Add New > General list, drag and drop a rich text element into the group box.

3. Select the rich text area element.

   This example illustrates the rich text area element being selected prior to rich text being added.

   

4. In the Field Attributes panel, click Edit to open the Rich Text Editor dialog box.

   Note: If needed, you can use the Description field to enter a description of the contents of the rich text area for other implementation team members. The description you enter only appears in the designer; it is not be displayed at run time.

5. Add text and use the desired formatting options.

6. Click OK.

7. Save your form layout.

Defining Fields Displaying a List of Values

This topic describes how to add a list-of-values to user-defined fields you add to your application forms manually.

Some of the user–defined fields that you can add to your form are considered “list-of-value” fields. List-of-value fields enable end users to select field values from a predefined set of values (a lookup list) to populate the field when entering data on the form. For example, radio sets and drop-down lists are list-of-value fields.

The list of values is a lookup type, and the individual items in the lookup list are lookup values.

When adding a list-of-value field type to your application form, you first add the field to the form, just as you would any other field. You then select an existing lookup type to associate with the field, or you can create a new lookup type if needed. To manage lookup types you use the Custom Lookups page.

This example illustrates the Custom Lookups page.

A list of values is a set of fixed field values defined for a specific purpose that is not expected to change over time. Removing items from the list, for example, could make previously saved data invalid.

An example of a field with a list of values could be the Property Zone Type field, where the values for a user to select are: Business, Residential, and Agricultural.

Identifying List of Value Type Fields

You associate a list of values with these field types:

• Radio button set

• Check box set

• Drop-down list

• Multi-select list

The following example illustrates a radio set, which is a set of radio buttons allowing a user to select a single value from the list of values.

Text surrounding the image describes it.

The following example illustrates a check box set, which is a list of multiple items allowing a user to select multiple values from the list of values.

Text surrounding the image describes it.

The following example illustrates a drop-down list, which is a list allowing a user to select a single value from the list of values.

Text surrounding the image describes it.

The following example illustrates a multi-select list, which is a drop-down list allowing a user to select multiple values from the list of values.

Text surrounding the image describes it.

Selecting an Existing Lookup Type for a Field

To select an existing lookup type:

1. Add the list-of-value type field to your form layout.

2. Select the new field.

3. Click Open Additional Attributes in the Field Attributes panel.

   This opens the Custom Lookups page.

4. On the Custom Lookups page, identify the lookup type to associate with the list-of-value field you added.

   Use the Meaning column to identify the appropriate list, or you can click View More Details to view the description and the actual lookup values in the lookup type.

5. Click Select in the Actions column to associate the desired lookup type with your field.

6. Close the Custom Lookups page.

7. Save the form layout.

Adding a New Lookup Type for a Field

1. Add the list-of-value type field to your form layout.

2. Select the new field.

3. Click Open Additional Attributes in the Field Attributes panel.

   This opens the Custom Lookups page.

4. On the Custom Lookups page, click Add.

5. On the Lookup Type Details page, enter these values.

   Page Element	Description
   Lookup Type	The system name, beginning with PSC, using uppercase letters, numbers, or underscores. For example, PSC_ROOF_TYPE. Note: All lookup types created and used within the Intake Form Designer must begin with PSC.
   Meaning	The value that appears in the Meaning column of the list of lookup types, which can help to identify the contents of the list. For example, Roof Type.
   Description	Provide any additional information to help identify the purpose and intended usage of the lookup type.

6. Add lookup values to the lookup type.

   1. Under Look Up Value, click Add.

   2. Modify these values:

      Page Element	Description
      Lookup Code	A short code used to identify the lookup value to the system, like a key value.
      Display Sequence	If required, you can set the sequence in which lookup values display in the lookup list, using a numeric sequence.
      Enabled	By default, a new lookup value is enabled. To disable a lookup value, turn off this switch.
      Start Date	Date on which a lookup value becomes valid.
      End Date	Date on which a lookup value is no longer valid.
      Meaning	The value that displays to the end user at runtime to select from the list.
      Description	Any additional information to describe the content or purpose of a lookup value.

   3. Click Save.

   4. Repeat for additional lookup values in the lookup type.

   Example:

   This example illustrates a completed lookup type with lookup values.

   

7. Close the Custom Lookups page.

8. Save the form layout.

Understanding the Scope of Lookup Types Created in the Intake Form Designer

The items in the following table describe the scope of the list of value fields that you can create and use in the Intake Form Designer.

Scope Item	Description
User-defined fields	You only can add to and modify the list of values associated with user-defined fields, which are the specific fields you have added to your application form manually. You can’t add or modify a list of values for a field contained within a delivered field group, such as the delivered Fence field group.
Intake Form Designer-only	The lookup types that you create within the Intake Form Designer can be used only within the Intake Form Designer, and only in specific circumstances can you associate a field in your form layout with lookup types created outside the Intake Form Designer. The interface used to create and select lookup types for use in your intake forms looks identical to the Lookups page (Navigator > Common Setup > Lookups), which is the interface used to manage lookups for Public Sector Community Development offering pages, such as the permit offering or the planning and zoning offering. However, the lookup types created on the Lookup pages can not be used for your intake forms nor visa versa. For example, you can’t use the UOM Type lookup type (ORA_PSC_CC_UOM_TYPE) from the Lookup Type page for your intake form fields.
Other licensed offering(s) in the same database	In select cases, if you are an existing Fusion Application Cloud customer, and you have other licensed offerings in the same database as the Public Sector Compliance and Regulation offerings, you can utilize lookup types not beginning with PSC for your intake form fields. For example, if you are a Fusion Application Cloud for Financials, which shares the same database as the Public Sector Compliance and Regulation offerings, you can select lookup types using the Intake Form Designer interface, assuming you are aware of the values it displays and how it is maintained. To access these lookup types, you need to modify the filtering on the Lookups page. Refer to the following example for more information.

Example: This example illustrates modifying the default filtering for the Intake Form Designer lookups.

To modify the filtering on the Lookup Type page:

1. Click the Filter By button.

2. Clear PSC from the filter field.

3. Click Apply.

This example illustrates using the Filter By button on the Lookup Type page to display more than just lookup types beginning with PSC.

Displaying Form Elements Conditionally

This topic describes how you can show or hide elements on your forms depending on selections users make on other form elements.

You can configure some form elements to be either displayed or hidden, depending on the value of other fields in the form. Form elements that can control the display of other elements are controlling elements, and form elements that can be shown or hidden based on the value of controlling elements are controlled elements. The following table describes the elements involved in conditional display.

For example, assume you wanted to display the Photovoltaic field group only if the user has selected the Solar single-item check box in a “Building Options” section of a permit application form. In this case, you can set the Solar single-item check box as the controlling element for the Photovoltaic field group, having the Photovoltaic element (the controlled element) display only when the Solar single-item check box is selected.

Display Type	Element Types	Description
Controlling Element	Single-item check box Switch	Form elements that determine whether another form element is displayed, depending on the value selected by the user. Note: Only single-item check boxes and switches can be controlling elements.
Controlled Element	Field group Group box	Form elements that can be displayed conditionally, depending on the value of the associated controlling element. To control when these elements appear, click the Control Display button on the Attributes tab, which appears only for these element types.

Procedure: Configuring Conditional Display

To configure conditional display for a form element:

1. Add the controlling element to a group box in your application form.

   The controlling element can be a user-defined element of these types:

   • single-item check box

   • switch

   Note: The controlling element must appear before the controlled element that references it.

2. Add the form element that you want to display or hide conditionally (the controlled element).

   The controlled element can be:

   • field group

   • group box

3. Select the controlled element you just added so that it is the active element in the layout.

4. In the Attributes panel, click Control Display.

5. On the Control Element Display dialog box, click Add to add a row to the grid, then double-click in the newly added row, and make the appropriate selections.

   This example illustrates the Control Element Display dialog box set to show a condition of a controlling element, such as hide this element if a switch element in the form is false.

   

   Element	Description
   Add	Click to add a new row to the grid. After adding a row, double-click the row to make it active. Note: If you add multiple rows of conditions to the grid, the system assumes an “OR” operator exists between each row. If any of the conditions are confirmed, that display option will be enabled.
   Delete	Click to delete the selected row in the grid.
   Display	Currently, Hide if is the only display option. You hide an element based on the value of the controlling switch or single-item check box, otherwise, the element is displayed.
   Controlling Element	Select the form element that will control the display of the selected predefined form element or group box. The drop-down list displays all user-defined switches and single-item check boxes that exist on or before the current page in the form. Selecting the controlling element appearing before the controlled element adheres to the logical sequence a user would take when completing the application form. Note: If the selected element is a group box, the drop-down list does not display any switches or single-item check boxes within that group box.
   Value	Select the value of the controlling element that determines when the display option will be rendered: True: A condition is true if a single-item check box is selected or a switch is on. False: A condition is false if a single-item check box is deselected or a switch is off.

6. Click OK.

7. Save your form.

The controlled element appears with an icon below the element label to indicate it is an item whose display is controlled by another element in the intake form.

This example illustrates the icon displayed for a controlled element.

Adding Logic

This topic describes how to add validation logic to form elements to validate the values added by end users. The language used for this logic is Groovy.

Groovy Overview

You can add validation logic to fields in your application form using the Apache Groovy programming language. Apache Groovy is an object oriented language that can be used for scripting or programming. Groovy is often referred to as an extension of the Java programming language and uses similar constructs and syntax. For Java developers, Groovy can be compared to other programming languages, such as Python or Ruby, that don’t intend to replace Java, but act as a companion language, extending capabilities and providing additional flexibility.

In the context of designing application forms, in the current release you use Groovy as a scripting language to create validator scripts to provide data integrity for end user input. A validator script is a logical construct that returns either true or false.

Currently, only simple field validation scripts are supported for your application forms.

For example, assume you have a form with the field, Number of Rooms, to indicate the number rooms in a structure, and you need to confirm that zero isn’t entered by the applicant. You could add the following simple validation script.

/* Field value for "Number of Rooms"  must be greater than zero.*/

newValue > 0 

The essential components of a validator script include:

• Groovy logic

• An error message

At runtime, if the field value entered does not meet your validation logic criteria during a save request, the system displays the error message to the user so they can resolve the issue.

Note: The Groovy validation executes only when the user either saves or submits the form. If there is any delivered validation for a field contained within a delivered field group, that delivered validation runs before any custom Groovy validation you have added. Before adding Groovy logic to a field delivered in a predefined field group, make sure to test the field group at runtime to become familiar with any delivered, internal validation.

Before adding Groovy validation, you will need to become familiar with the Groovy language and how it is intended to be used within Oracle applications.

For more information on Groovy usage within Oracle, refer to Oracle Applications Cloud: Groovy Scripting Reference.

For general information on the Groovy language, see Apache Groovy documentation.

Setting the Scope of a Groovy Script

The following table outlines the possible scope of a Groovy script.

Scope	Description	Where Set
Field	You can add Groovy logic to act on a single field. The code you add runs only against the selected field. You can add Groovy to fields in delivered field group or to user-defined fields you have added manually.	Select the field to which you want to add validation logic, and click Add Logic in the Field Attributes panel for that field.
Object	If your script involves more than one field, you need to add that code at the object level. The object refers to the current application form you are creating. For example, if you are creating a fence permit, the logic you add for the current object applies to fields in that fence permit definition. Note: To get the field names of each field you want to reference in your object-level script, you need to select that field, click Add Logic, and copy the field name provided in the comments in the Groovy Script Editor.	When in the designer with the application form open, click the Add Logic button at the top of the form, next to the Preview button.

Note: For validating at the field level use newValue and oldValue to reference the current field. At the object level, use the field name, such as NumberofRooms_c to reference fields.

Note: In the case of multiple field-level validations, each runs independently. However, in the case of object-level validations, the object-level validation runs only if all field-level validations have passed.

Working with the Groovy Script Editor

To access the Groovy Script Editor:

1. Save the intake form you are creating.

   The field(s) you reference in your logic at the field level or the object level must exist in the underlying database object, which occurs when you save the form after adding any new elements.

2. Click the Add Logic button in the Field Attributes panel or in the intake form header.

   When clicking Add Logic in the Field Attributes panel, your code operates at the field level. When you click Add Logic in the intake form header, your code operates at the object level.

The following example illustrates adding validation logic to a field using the Groovy Script Editor.

Page Element	Description
Work Area	In the work area, add your validation logic. The first line in comments (/* <text> */) is automatically generated, and it provides you the field name and object name as they are referenced internally. For a field contained in a delivered field group, the field name will be similar to the field label, such as DemOverallHeight. In the case of a user-defined field, the field name will match the field label you have entered, with a “c” as a suffix to indicate it is a custom field. For example, if you have a user-defined field named Rooms, the field name appearing in the script will be Rooms_c. The custom object name is the type code as defined on the Transaction Type page, with either a “LNP1” or “PZ1” prefix and a “c” suffix. “LNP1” is the prefix for permits and “PZ1” is the prefix for planning and zoning applications. For example, if the Transaction Type Code is Fence, the custom object name in the script will be LNP1Fence_c. Note: For validating at the field level use newValue and oldValue to reference the current field. At the object level, use the field name, such as Rooms_c.
Script Name	By default, the script name follows this structure: field_validator or object_validator You can change the script name if needed.
Description	Add text to describe the purpose of the script.
Error Message	Provide the message that the system displays the user if the data entered for the field does not pass the validation logic. The validator script returns either true or false. If the return is false, the system displays the error message.

Note: While you can delete fields with Groovy logic associated with them, make sure the Groovy logic evaluates to True prior to deleting the field, otherwise you risk making the entire transaction type invalid.

Adding Contextual Help to Forms

This topic describes how to add help text to various parts of your intake forms to aid citizens when they are filling out an application form.

Working with Contextual Help

If you determine that the end user needs additional information to understand a user-interface element in your intake form, you can add contextual help text to that user-interface element. If you add contextual help to a user-interface element in your intake form design, the system displays a Help icon next to the label of that user-interface element.

You can see the Help icon in both the design and runtime mode. At runtime, end users click the Help icon to display your help text in a popup, without leaving the page.

Note: At design time, the Help icon does not display the help text popup when clicked.

You can add contextual help text to these intake form elements:

• Page tabs

• Field groups

• Group boxes

• Fields (applies to fields in field groups and to custom fields)

Note: For group boxes and field groups, you can add help only when with the Show Label attribute turned on.

You can’t add contextual help text to these intake form elements:

• Radio sets

• Check box sets

If you need to add help for radio sets or check box sets, use a group box to contain the control and add the help text to the group box container.

Adding Contextual Help

To add contextual help:

1. Select the page element to which you want to add contextual help.

   Note: You cannot add help text directly to radio sets and check box sets. Add help text to a group box surrounding the radio sets or check box sets.

2. Click the Help button in the attributes panel.

3. On the Contextual Help Setup page, note the Type Code, Page Name, and Page Object values.

   These values uniquely identify the page element to which you are associating the contextual help. You can’t change these values. They are read-only and maintained by the application.

   Item	Value
   Type Code	An automatically generated value consisting of the internal product code and the permit type code derived from the permit type definition.
   Page Name	The name of the page tab on which you are adding help. Regardless of what the page label is on the tab, the application displays each tab using the default name in sequence, such as tabs1, tabs2, and so on. For example, the second page tab in an intake form may have the name Fence Information, however in the Page Name field it will appear as tabs2.
   Page Object	Identifies the page element for which you are adding help. Regardless of the page element’s label, the application displays the internal naming convention as the field value, which is the page element type code + sequence added. For example, for the second field added to the form the field value is fields2, which indicates the element is a field and it is the second field added to the form. The page element type codes are: Field groups: ccas Group boxes: widgets Fields in field groups: <field group>_<internal field name> (such as ccas2_ReleaseDate) Custom Fields: fields

4. In the Description field, add text to describe the purpose of the help text so other implementation team members can understand the content.

5. Click the Add New button in the Contextual Help Details grid to display the Add Context Help Details dialog box.

6. Select Agency Defined from the Type drop-down list.

   Note: Help topics of type System Defined are provided by Oracle and should not be altered or removed. Customers should use the Agency Defined help topic type to add help topics specific to your implementation. If you want your custom help text to display instead of delivered help text, disable the System Defined help topic, create your custom topic, and enable it.

7. Activate the Help Content edit box by clicking to the right of the Help Content field label.

8. In the Help Content edit box, enter your help text.

   The system provides rich-text editing features, which enables you to implement limited formatting options, as needed.

9. When you’ve added the content, and you are ready for it to be viewed by end users, turn on the Enabled switch.

   Note: To prevent the help content from displaying at run time, turn off the Enabled switch.

10. Click Save on the Contextual Help Details page.

11. Click Save on the Contextual Help page.

12. Confirm that the help icon appears on the page tab or next to the page control label in your intake form design.

For more information on contextual help, see Setting Up Contextual Help.

Setting Form Options

This topic describes the options you can set for the entire form to control the ways citizens interact with the form.

Enabling the Review Page

The review page presents all the fields of a multi-tab form on a single, scrollable page for efficient review of the entered data prior to submitting the form.

By default, the review page displays:

• Form fields as read-only, but the end user can click the Edit button for each field group to modify the fields as needed.

• All field groups expanded.

• For multi-page view or single-page view.

• For all forms, unless disabled.

To disable the review page:

1. In the Intake Form Designer, click the Form Options link.

2. On the Form Options dialog box, turn off Review Page.

3. Click OK.

4. Click Save.

Setting a Confirmation Step

You can enable one of the pages in a form as a confirmation page to display after the end user has filled in the information and submitted the form. You create the confirmation step in the designer and then set it to be the confirmation step in the Form Options.

When set as the Confirmation Step, the page displays:

• At design time with the page tab filled in grey to indicate it is the confirmation step.

• At runtime as the last page in the train stop drop-down list.

Note: The confirmation step does not display as part of the single page view.

To enable the review page:

1. In the designer, click the Form Options link.

2. On the Form Options dialog box, select the desired page from the Confirmation Step drop-down list.

3. Click OK.

4. Click Save.

Mapping Form Fields to Decision Model Attributes

This topic describes how the fields added to an intake form in the designer are mapped to the fee model defined for the transaction type.

The Fee Mapping page in the designer is used to map attributes in the decision model to the fields added to the intake form. The Fee Mapping page is step 2 in the Intake Form Designer, where designing the layout is step 1.

This image illustrates Step 2 of 2: Fee Mapping in the design of a permit application.

You assign a fee schedule to an application type on the Transaction Type page using the Fee Schedule field. You map attributes from the fee schedule’s underlying decision model created in Oracle Integration Cloud to the fields you have added to your intake form either through delivered field groups or by adding fields manually.

Note: Not all model attributes need to be mapped. Because a fee schedule can be reused by multiple transaction types, only the model attributes required for fee calculations for the current application type need to be mapped. All other model attributes can be left blank.

For more information on setting up fee schedules, see Setting Up Fee Schedules.

For more information on decision models, see Creating Decision Models for Fees.

Mapping Application Fields to the Fee Item in the Decision Model

To access the Fee Mapping page in the form designer:

1. Navigate to the Transaction Type page:

   • Permit Setup > Permit Type

   • Planning and Zoning Setup > Planning Application Type

2. Select the transaction type that you want to view in the designer.

3. Click the Design Form button.

4. Click the Next button while in the application form setup step.

5. The fields on the Fee Mapping page are as follows:

   Page Elements	Description
   Model Attribute	The name of the attribute as it appears in the decision model in Oracle Autonomous Integration Cloud. Not all model attributes must be mapped. Because fee schedules can be reused by multiple transaction types, only the model attributes required for fee calculations for the current transaction type need to be mapped. All other model attributes can be left blank.
   Attribute Type	The data type of the model attribute, such as string, number, boolean, and so on.
   Record Type Attribute	The field added to the intake form layout either contained in a predefined form element or a user-defined element you have added manually.

6. Select the record type attribute from the drop-down list that you want to map to the decision model attribute.

7. Click Save.

Considering User Experience

This topic describes concepts related to using forms that implementation teams need to consider when designing forms.

Required Fields

The system validates that required fields contain values prior to a save request at runtime.

If a required field is empty the system displays the following error message on the page.

This example illustrates how the system displays messages to indicate what is required for a field.

In addition to the message, the system disables the Save button until the required field values have been provided.

The system also displays an itemized list at the top of the form when clicking Save so that in the case of multiple pages, the user can navigate quickly to the item and provide an acceptable value. The error message lists the error and the location to which the end user must navigate to correct the error. The list if errors can be expanded and collapsed as needed.

This example illustrates an error message appearing at the top of the form, displaying in the list the error, and the location of the offending field.

Runtime Application Form Save Behavior

When an end user navigates to another page in the application form using either the train stop drop-down list or the Next button, the system automatically:

• Saves the currently entered data.

• Performs data validation on the current page.

If the end user attempts to navigate away from the application form page using, for example, the back button, entering a different URL, or reloading the page, the system checks for any unsaved changes or new data. If the changes or new data have not been saved, the system displays a message to the user indicating that if they continue, unsaved changes and new data will be lost. The user can elect to leave the page or remain on the page to save.

Runtime Train Stop Drop-Down Behavior

The train stop drop-down list, appears in the center of the application form header to provide:

Feature	Description
Context	The system automatically prepends the appropriate step number to the application form page name. The step numbers are assigned in the order the pages appear in the designer (from left-to-right). For example, assume you have three pages in your form: Application Details, Fence Details, Property Details. The train-stop drop-down list displays the pages as: Step 1: Applicant Details Step 2: Fence Details Step 3: Property Details
Current Page	To show the current page the user is viewing, the system displays a single, right-pointing, chevron character (>) to the left of page label in the drop-down list.
Navigation	Select any page in the application form, including the review page, to access it immediately.
Switch to Single/Multi-page view	Toggle between the multi-page view or the single-page view.

Using the Single-Page View

When accessing the single-page view in review or advanced-edit mode, end users will notice these characteristics of the page elements.

Page Element	Behavior
Edit button	Enables the end user to activate the form fields for editing. Initially, the system displays them in read-only mode. Once clicked, the system toggles the Edit button to the Done button.
Done button	Once the end user completes any changes, clicking Done: Performs any configured data validation. Saves changes to the database. Returns the form fields to read-only. Toggles the button back to read Edit.
Group boxes	If a group box contains multiple group boxes, only the outer (parent) group box displays an Edit/Done button.
Field groups	If there are multiple field groups in a group box, they will appear to be a single page section, with one Edit/Done button controlling all the field groups within the parent group box. Otherwise, if the field groups are on the page tab separately (not within the same parent group box container), then the system displays an Edit/Done button for each field group.
Expand All/Collapse All	Expands or collapses all the elements on the page, including group boxes and field groups within parent group boxes.

Note: The Edit button and the Done button do not appear on a page rendered in advanced edit mode if the form is displayed in a read-only context. For example, if the user viewing the form does not have sufficient privileges or if the user has already submitted the form, the fields in the form will be disabled and the Edit button and Done button will not be rendered on the page.

Advanced-Edit Mode

If needed, agency staff members can update a form after a citizen has submitted the form. Agency staff members access the submitted form using the Permit Details page in the Permit List or by deep linking. Editing a form after a citizen has submitted it is referred to as advanced-edit mode.

When in advanced-edit mode, the system:

• Displays only the field groups enabled for advanced-edit mode.

• Presents the form in the single-page view.

Agency staff members click the Edit button to activate fields and update data, and they click Done to save changes.

Note: Customers cannot configure whether a delivered field group appears in advanced-edit mode. Field groups enabled for advanced-edit mode are controlled and delivered by Oracle development. Only the field groups that are appropriate for agency staff members to update are enabled for advanced-edit mode.

Testing Intake Forms

This topic describes the methods and considerations involved with testing your application forms.

You design, create, and test application forms on your development or test environment. Depending on what you have licensed, you may have a combined development and test environment, or you may have a separate development and test environment. You can test forms both inside and outside sandbox mode.

Once your forms have been created and thoroughly tested, you then migrate the newly created forms to your production system for public access.

Testing Forms Inside the Sandbox

You can test draft application forms in the sandbox using the Intake Form Designer preview mode. To enter preview, click the Preview button.

In preview mode, you can test the layout of the user interface and the tab flow in a simulated runtime scenario. The preview mode does not enable you to enter data and save it. To test the full functionality and data validation of your intake form, you must first publish the form in your test system, as described in the following section.

Note: The Intake Form Designer does not activate the Save button in preview mode.

Testing Forms Outside the Sandbox

Once you are done testing the configuration of your form and the layout of the user interface using preview mode, you can begin testing your form in scenarios that end users will encounter when they interact with your intake form. To do this, you need to publish your form on the test environment.

For more information on publishing forms, see Publishing Intake Forms.

Note: The testing data you enter and save during testing remains in the underlying database tables after the form is migrated to the production system.

Migrating Application Forms Between Environments

After you have completed your testing of the application form on the test environment, follow the procedure in Functional Setup Manager for migrating transaction type metadata and intake form layout metadata from the test database to the production database.

For more information on test-to-production data migration, see Managing Transaction Type Configurations.

Publishing Intake Forms

This topic describes the steps to complete to publish intake forms.

To make your application forms available on public landing pages, you need to publish your form.

To publish a form:

1. Confirm that you have saved and tested all changes made to your form.

2. In the Intake Form Designer, click Publish.

3. Navigate to the Transaction Type page:

   To navigate to the Transaction Type page you can either click Back in the global header, or select Permit Setup > Permit Type.

4. On the Transaction Type page, open the appropriate transaction type, and set these values:

   • Transaction Type Status: Ready

   • Public User Enabled: Enabled for all users or Enabled for registered users.

5. Click Save.

Note: After publishing a transaction type, if you attempt to access the application from a landing page and the application displays an error, make sure the Transaction Type Status and Public User Enabled attributes are set correctly.

Note: After publishing a transaction type application, the application may not be accessible immediately. It can take several minutes to apply the most recent changes and transfer the application from the sandbox to the live runtime system.

Cloning Transaction Type Definitions

This topic describes how to clone transaction type definitions and the associated form design. It also covers the attributes that will be shared between the source and clone definition and the attributes you will need to modify on the cloned definition.

You can clone a transaction type to:

• Save time when creating a similar transaction type, rather than creating a new transaction type for each situation from scratch.

• Create a new version of a currently published transaction type after making a significant correction or addition to the transaction definition.

In some cases, it may be more efficient to create a new transaction type and form, while in other cases, it may be more efficient to clone an existing transaction type and form.

When you clone a transaction type, you make a cloned copy of:

• Most of the transaction type metadata, such as the specified Classification, Auto Number Rule, Department, Fee Schedule, and so on. Some of the metadata is not cloned, such as Transaction Type, Transaction Type Code, Transaction Type Status, Help Text and so on, as you’ll need to modify those values for the cloned copy.

• All of the intake form layout in the Intake Form Designer, including pages, group boxes, field groups, and user-defined fields you have added to your application form.

When deciding to clone a transaction type, you may consider:

• The number of fields and pages within the existing application form layout that you’d need to change.

• Similarity between the existing transaction type and new transaction type.

• Number of shared attributes.

Note: In general, if you intend to make numerous modifications to the cloned copy, it may be more efficient to start a new transaction type from scratch.

When cloning to make a new transaction type, you will want to make sure you are aware of:

• The attributes that will be shared between the source definition and the clone.

• The attributes you need to modify to create unique values between the source definition and the clone.

Note: All modifications you make to a should be done in your test environment and not on your production environment. After you have thoroughly tested your changes in the test environment, your modifications should be migrated using the Functional Setup Manager task flows.

Transaction Type Metadata Considerations

All of the field values on the Transaction Type page will appear in the cloned transaction type, except for selected field values listed in the following table.

Make sure to update any of the copied information on the Transaction Type page to reflect the requirements of the new transaction type. For example, if the Department, Fee Schedule, or Workflow information, should be different, make sure to update it for the new transaction type definition so it is associated with the correct items.

Page Element	Description
Type	The type name doesn’t have to be unique. You can create a new transaction type by using a unique value or enter the same value as the source transaction type, if you are creating a new transaction definition with the same transaction type.
Type Code	The type code must be unique. Enter a transaction type code that identifies this version of the transaction type definition.
Status	Initially, for a newly created transaction type the status on the Transaction Type page is always set to Preliminary. After you publish the form, change the status to Ready for Use.
Valid From Date	The application inserts the current date for the cloned transaction type.
Valid To Date	Update to reflect your business requirements.
Public User Enabled	Initially, for a newly created transaction type this is always set to Not enabled for public users. When you are ready to publish the new transaction type, update this value.

For more information on the fields on the Transaction Type page, see Setting Up Permit Types.

Intake Form Layout Attribute Considerations

The following table addresses specific considerations for UI elements in your form layout with respect to cloned transaction types and application forms and how any changes you make to the cloned definition may affect the source definition.

Element	Description
Field groups	The cloned copy of the transaction type contains the same layout as the source definition. If the intake form utilized any of the delivered field groups, the application copies the field groups into the cloned copy of the definition, using the same layout as the source definition. For example, if you added the Fence field group to the source permit definition to the second page tab, the Fence field group would appear in the cloned copy of the transaction type on the same page tab.
Labels	The labels for fields and UI elements, such as pages, group boxes, field groups, and so on, are the same between the source and cloned definition.
User-defined fields	Any fields you have added manually to the source will be copied, as is, to the cloned definition. For any fields that you have defined a list of values, make sure it applies to your new transaction type.
Security	The cloned definition will have the same security configuration as the source definition for: Data security for column authorization and data redaction. Cases where Hide from public user has been implemented.
Help	If any help has been added to the form for a page, field group, group box, or field, for the source definition, the application does not copy help references into the cloned definition. Note: You can remove the help references from the cloned form, but do not delete the help text from the Contextual Help page if other forms are still using that help text.

You are also cloning the fee mapping, which is defined in the second step of the Intake Form Designer.

Cloning a Transaction Type to Create a New Transaction Type

When you clone a transaction type, you also clone the associated form design. You can clone just the transaction type definition without cloning the application form design; however, you can’t clone just the form design by itself.

Note: When you clone a transaction type, the type status defaults to Preliminary on the new transaction type, and the status of the new application form defaults to Draft in the Intake Form Designer.

This example illustrates the Clone Permit Type page, which is described in the steps for cloning a permit type.

To clone a transaction type:

1. Select Permit Setup > Permit Type.

2. Open the desired transaction type.

3. Click the Clone button.

4. On the Clone Type page, enter the following values:

   Page Element	Description
   New Transaction Type	Enter a transaction type name. The transaction type name can be the same as an existing transaction type name so that you can have different versions of the same transaction type. For example, if the original transaction type name is Fences, you can reuse the name for the new transaction type definition, but you must enter a unique type code to distinguish the two.
   New Transaction Type Code	Enter a unique transaction type code. Oracle recommends manually adding a version number to the source transaction type code if you want different versions of the same transaction type definition. For example, if the original type code is Solar-001, you can enter a new code, Solar-001-v2
   Use Original Workflow Setup	Turn on the switch to use the original workflow setup as defined in the original transaction type. Turn off the switch to leave the workflow setup fields blank on the new transaction type. You must enter a workflow setup values.
   Clone Form Design	Turn on the switch on to clone the application form design associated with the original transaction type. Turn off the switch to create a completely new application form using the Intake Form Designer.

   Note: Providing a unique type code is required to make the transaction type definition unique.

5. Click the Create button.

   The cloning process opens the cloned copy of the transaction type.

   Note: When saving the cloned definition, the application places the cloned definition within a sandbox.

6. Make any other required changes to the cloned transaction type definition and form design.

   See the previous sections for more information regarding what items to check.

   Note: If there are numerous custom fields in the application form, when you have the layout open in Intake Form Designer, it can take several minutes to perform the initial save. While saving, the application is creating all of the custom fields, creating the other elements, and running validation.

7. Publish the application form in the Intake Form Designer.

   For more information on publishing a transaction type, see Publishing Intake Forms.

8. Return to the Transaction Type page to change the status to Ready for Use.

Considerations for Creating a New Version of a Transaction Type Using Cloning

In some cases, you may want create a new version of an existing, published transaction type to correct an error or make a change.

If the change made is insignificant, as in it does not change the meaning of a field or page element, then in most cases cloning is not required, and you can simply make the change directly to the transaction type definition. For example, assume you have a field for an email address on your form, and it had been requested to change the label from E-mail to Email (removing the hyphen). In this case, the change can be made directly to the form and republishing it.

However, in other situations, the change may be significant, in that it affects reporting associated with transaction type, alters historical data, makes future data out of sync with historical data, and so on.

Significant changes where cloning a transaction type is recommended include:

Transaction Type Element	Examples of Significant Changes
Field groups	Changing the label of a field group. Adding Removing Updating the security (Hide from public user) Changing the label, hidden, or required setting of a field within a field group.
User-defined form elements	Adding Removing Setting to required Updating a default value Updating the security (Hide from public user)
HTML UI constructs	Adding page tabs Removing page tabs Adding group boxes Removing group boxes

Creating a New Version of a Transaction Type Using Cloning

Creating a new version of a transaction type using the cloning feature involves:

• Deactivating the published version of the transaction type.

• Cloning the published version of the transaction type.

• Activating the cloned copy of the transaction type.

To deactivate a published transaction type:

1. Select Permit Setup > Permit Type.

2. Open the definition for the published transaction type.

3. Set the Transaction Type Status field to Void.

4. Click Save.

To clone the published transaction type:

1. With the transaction still open from the previous steps, click Clone.

2. Enter the same Transaction Type value as used for the recently deactivated transaction type.

3. Enter a unique Transaction Type Code.

   Note: Providing a unique transaction type code makes the transaction type definition unique. To keep track of versions, you can add v2, v3, v4 to the code, for example.

4. Save the cloned definition.

   Note: When saving the cloned definition, the application places the cloned definition within a sandbox.

5. Make any other required changes to the cloned definition transaction type and form design.

   See the previous sections for more information regarding what items to check.

6. Click Publish in the Intake Form Designer to publish the cloned definition.

   For more information on publish a transaction type, see Publishing Intake Forms.

To activate the new transaction type:

1. Select Permit Setup > Permit Type or press Back from the Intake Form Designer interface.

2. Open the definition for the published transaction type.

3. On the Transaction Type page, set these values:

   • Transaction Type Status: Ready for Use.

   • Public User Enabled: Enabled for all users or Enabled for registered users.

4. Click Save.

Managing Transaction Type Configurations

This topic describes the considerations and steps related to migrating transaction type definitions, such as permits or planning and zoning applications, from your test environment to your production environment.

Transaction Type Lifecycle Overview

Any implementation of Oracle Applications Cloud usually requires migrating setup data from one environment to another at various points in the subscription lifecycle.

For example, you set up your initial configuration of the Public Sector Community Development services in the test environment, which is your source system. Then, after thorough testing and verification, you move the setup and configuration data from your test environment to the target environment, which is your production system.

You use the Fusion Applications Functional Setup Manager to perform these migration tasks.

This example illustrates that you use Functional Setup Manager to migrate data between your test and your production environment.

You access Functional Setup Manager from within Public Sector Community Development by selecting Navigator > Setup and Maintenance or by clicking the Setup and Maintenance tile on the springboard. To access Functional Setup Manager, you need to have the System Administrator role associated with your user account.

The functional areas in Functional Setup Manager that apply to your transaction type definitions and application form definitions are:

Offering	Functional Area
Public Sector Permits	Permit Types
Public Sector Planning and Zoning	Planning Application Types

Like using Functional Setup Manager to setup your configuration, when migrating data, you use a top-down approach. That is, if you are not exporting the entire configured offering, and you are exporting by functional area, you need to export the functional areas in the order they appear.

For more information on using Functional Setup Manager, see Using Functional Setup Manager.

Note: All configuration changes should be completed and tested in your test environment and then migrated to the production environment. Changes made directly to the production environment might be overridden during subsequent test-to-production migration activity.

For additional information related to migrating configuration data from your test environment to your production environment for the Public Sector Compliance and Regulation offerings, see Oracle Public Sector Community Development: Test to Production (Doc ID 2551940.1) on My Oracle Support.

Set the Target Instance URL

On the source system (your test environment), you need to define the URL target system (your production environment) so that setup data and configuration data can be sent to the target.

To set the target instance URL:

1. Sign on to the test environment.

2. Click the Setup and Maintenance tile on the springboard to access Functional Setup Manager.

3. On the right side of the Functional Manager Setup interface, click the Tasks tab to open the Tasks drawer.

4. Click Search, and search for Manage Configuration Set Migration Target Security Policy.

5. On the Manage Configuration Set Migration Target Security Policy page, enter the URL for your target environment, and the appropriate security credentials for the System Administrator role.

   Note: It is recommended to include the port number when you specify the URL value. For example:https://server.example.com:443You can get the target port value by accessing the Manage Configuration Set Migration Target Security Policy page on your production system (your target).

6. Save.

Managing Unified Sandboxes on the Source and Target System

Public Sector Compliance and Regulation requires the Unified Sandboxes feature to be enabled on your test environment, where you are actively designing and configuring your implementation. It is recommended that you disable the Unified Sandboxes feature on your production system.

For migrating transaction types from your test system to your production system, especially, make sure to disable the Unified Sandboxes feature on your target, production system. Because you should be completing all configuration tasks on your source test system, sandboxes shouldn’t be required on the production system. Having the Unified Sandboxes enabled on the production system can cause the Configuration Set Migration utility not to render or function properly.

To disable Unified Sandboxes:

1. Sign on to your target, production system.

2. Navigate to Functional Setup Manager.

3. Select your solution, such as Public Sector Permits or Public Sector Planning and Zoning.

   Note: Disable Unified Sandboxes in all solutions you have licensed for Public Sector Compliance and Regulation.

4. Click the Change Feature Opt In link.

5. Locate the Application Extensions feature, and click the pencil icon in the Features column.

6. Make sure the Unified Sandboxes feature is disabled.

   Note: If there are any open sandboxes, they need to be deleted or published before you can disable this feature.

7. Click Done.

Migrating Transaction Type Foundational Metadata

Before you use Functional Setup Manager to export transaction type configuration data, you need to create and migrate a configuration set, which includes the underlying metadata required to be in place as a prerequisite prior to migrating other transaction type setup data.

Because the Public Sector Compliance and Regulation solutions are metadata-driven, you need to migrate the metadata that is the foundation of the transaction definitions. This is the data stored in the Oracle Medata Services (MDS) layer. You do this by creating a configuration migration set. Once that is complete, you can then begin using Functional Setup Manager export and import features to transfer the rest of required definitions between test and production systems.

Note: Before you migrate transaction type metadata from your test system, ensure that the transaction type definitions and associated intake forms are complete, tested, and published.

Caution: These steps must be completed before you use the Functional Setup Manager export and import options.

To migrate transaction type metadata:

1. Sign on to the test system, which is the source system.

2. Click the Setup and Maintenance tile on the springboard to access Functional Setup Manager.

3. Select the appropriate offering (Permits or Planning and Zoning).

4. Expand the Permit Types or the Planning Application Types functional area (depending on your offering).

   Note: These steps for creating a migration set apply only to the Permit Types and the Planning Application Types functional areas.

5. Click the Manage Permit Configuration task or the Manage Planning Application (depending on your offering).

   This example illustrates selecting the option Manage Permit Configuration, which you select to set up and migrate a configuration set.

   

   Note: This link takes you to the Manage Configuration Set Migration Target Security Policy. You can also access this page in Fusion Application by selecting Navigator > Configuration > Migration.

6. If you have not already specified your target instance URL, you must do that prior to the next step.

   See the previous section for more information.

7. Select the Outgoing tile and create an outgoing migration set to export to your production environment.

   When creating a configuration set, the utility compares differences between source and target, and determines the metadata that needs to be exported to the target system. When the process is complete, the resulting migration set is downloaded in the form of a downloadable jar file.

8. After finishing the creation and migration of the outgoing migration set, sign on to the production system (the target system), and complete the steps for applying the incoming migration set.

This example illustrates an incoming configuration set.

For more information on these steps, refer to Oracle Applications Cloud documentation: Configuring and Extending Applications.

Exporting and Importing Remaining Transaction Type Data

After you have completed migrating the configuration set on the source system, you then export the remaining transaction type data using the Functional Setup Manager options for the functional area or the entire offering.

Note: You can export and import at the functional area-level by selecting the Actions button for the functional area or at the entire offering level by selecting the Actions button at the top right.

This example illustrates using the functional area export options.

After exporting from the test system, you then sign on to the production system and import the corresponding business object data.

When you export business object data, you have the option to select only those business objects that you utilize. For example, if you are not using application groups, you could deselect Manage Application Groups from the Business Objects list.

The objects you export will be in the form of a downloadable jar file.

For more information on these Functional Setup Manager export and import features, see:

Using Functional Setup Manager: Managing Setup Using CSV File Packages

Using Functional Setup Manager: Exporting and Importing Setup Data