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.
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.

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

Intake Form Layout Attribute Considerations

The following table describes specific considerations for UI elements in your form layout with respect to cloning transaction types and what gets copied from the initial source intake form to the target clone.

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.
Groovy scripts	If any Groovy logic has been added to the source intake form, the cloning process does not copy the Groovy logic into the target clone definition.
Fees	Any fee mapping, which is defined in the second step of the Intake Form Designer, is copied to the target clone definition.

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 permit transaction type:

Select Permit Setup > Permit Type.
Open the desired transaction type.

Note: Only transaction types with a status of Published can be cloned.
Click the Clone button.

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.

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.
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.
Publish the application form in the Intake Form Designer.
For more information on publishing a transaction type, see Publishing Intake Forms.
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:

Select Permit Setup > Permit Type.
Open the definition for the published transaction type.
Set the Transaction Type Status field to Void.
Click Save.

To clone the published transaction type:

With the transaction still open from the previous steps, click Clone.
Enter the same Transaction Type value as used for the recently deactivated transaction type.
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.
Save the cloned definition.

Note: When saving the cloned definition, the application places the cloned definition within a sandbox.
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.
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:

Select Permit Setup > Permit Type or press Back from the Intake Form Designer interface.
Open the definition for the published transaction type.
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.
Click Save.

Impact of Updating Existing Transaction Types and Republishing

This table describes the impact of various changes when you update and republish a transaction type.

Modification	Impact
Update a label for a user-defined field	Submitted transactions: applies to all submitted transactions. New transactions: available on all new transaction intake forms. Auditing: No impact. Labels don’t appear in auditing; the audit goes against the field IDs. Reporting: OTBI: no impact to OTBI, which doesn’t incorporate fields. CSA: New label will not appear in CSA. Manual update of the label in CSA and republish. Once done this applies to all transactions, old and new. BIP: if BIP depends on CSA, then the BIP report template needs to have the new label manually updated.
Add a new user-defined field	Submitted transactions: the field will appear on all submitted transactions, which means if an update is required for a submitted transaction this field will also appear on the page and be part of the payload. New transactions: the field appears on all new transactions. Auditing: available for auditing, but the field needs to be added to the auditing report. Reporting: CSA: available after you edit the CSA, include the new field, and republish. BIP: available after the new field is included in the report template and the CSA is republished.
Set a field as required	Submitted transactions: any update to the transaction will require that this field have a value. New transactions: appear as required for any new transaction. Auditing: no impact. Reporting: n impact.
Add or edit Groovy script	Submitted transactions: if modifying, the new logic will fire. New transactions: applies to all new transactions. Auditing: no impact. Reporting: no impact.
Hide a field	Submitted transactions: field will be hidden for all submitted transactions. New transactions: hidden for any new transactions. Auditing: field would be still part of the audit report until removed. Reporting: BIP - remove from template CSA: manually remove field from CSA and republish, BIP: manually remove field from template.
Add a user-defined list of values (LOV) field	Submitted transactions: applies to all submitted transactions. New transactions: applies to all new transactions. Auditing: same as adding a user-defined field. Reporting: same as adding a user-defined field.
Add or edit a list of values (LOV)	Submitted transactions: no impact. New transactions: applies to all new transactions. Auditing: no impact. Reporting: immediately reflected in CSA.
Update list of values (LOV) display criteria (Enabled/Disabled) (Start Date/End Date)	Submitted transactions: applies to all submitted transactions. New transactions: applies to all new transactions. Auditing: no impact. Reporting: immediately reflected in CSA.
Add or edit control display settings	Submitted transactions: may impact submitted transactions. New transactions: applies to all new transactions. Auditing: no impact. Reporting: no impact
Make changes to reusable field	Submitted transactions: applies to all submitted transactions. New transactions: applies to all new transactions. Auditing: available for audits after being incorporated into the audit report. Reporting: no impact.

Impact of Cloning the Transaction Type and Retiring the Previous Version

This table describes the impact of various changes when you clone a transaction type to replace the previous version.

When cloning, you are creating a new transaction type, so in general, you should expect these impacts as the standard update:

Auditing: any new transaction that is created is available to audit framework, which requires you to enable the object to be audited and configure the report as needed.
Reporting: a new CSA needs to be created for each new transaction type.

Modification	Modification
Update a label for a user-defined field	Submitted transactions: no impact as there are no submitted transaction yet. New transactions: appears for all new transactions. Auditing: standard uptake. Reporting: standard uptake. You can reuse the same BIP or create a new BIP template.
Add a new user-defined field	Submitted transactions: no impact. New transactions: appears for all new transactions. Auditing: standard uptake. Reporting: standard uptake. You can reuse BIP template after editing and republishing or create a new BIP template.
Set a field group field or a user-defined field as required	Submitted transactions: no impact. New transactions: appears for all new transactions. Auditing: standard update. Layout changes are not auditable. Reporting: no impact to BIP.
Add or edit Groovy script	Submitted transactions: no impact. New transactions: appears for all new transactions. Auditing: Groovy changes are not tracked by audits. Reporting: no impact to BIP. Groovy changes to not affect reporting.
Hide a field	Submitted transactions: no impact. New transactions: appears for all new transactions. Auditing: layout changes are not tracked in Audits. Reporting: no impact to BIP. Layout changes are not reflected in reporting.
Add a user-defined list of values (LOV) field	Submitted transactions: If the LOV is pointing to an existing list then updates to this list will affect submitted transactions. If a new list is created for the user-defined field, then there is no impact to existing fields. New transactions: appears for all new transactions. Auditing: same as adding a user-defined field. Reporting: no impact to BIP.
Update a user-defined list of values (LOV)	Submitted transactions: If the LOV is pointing to an existing list then updates to this list will affect submitted transactions. If a new list is created for the user-defined field, then there is no impact to existing fields. New transactions: appears for all new transactions. Auditing: no impact. Reporting: LOVs are immediately reflected in CSA.
Update list of values (LOV) display criteria (Enabled/Disabled) (Start Date/End Date)	Submitted transactions: If the LOV is pointing to an existing list then updates to this list will affect submitted transactions. If a new list is created for the user-defined field, then there is no impact to existing fields. New transactions: appears for all new transactions. Auditing: no impact. Reporting: may affect reporting on submitted transactions as both values can be incorporated depending on date settings.
Control display settings	Submitted transactions: no impact. New transactions: applies to all new transactions. Auditing: no impact. Reporting: no impact.
Reusable custom fields	Submitted transactions: applies to all submitted transactions. New transactions: applies to all new transactions. Auditing: standard uptake. Reporting: not currently supported.