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.
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.
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:
|
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.
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.
To clone a permit transaction type:
Select
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 |
|
User-defined form elements |
|
HTML UI constructs |
|
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
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
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 |
|
Add a new user-defined field |
|
Set a field as required |
|
Add or edit Groovy script |
|
Hide a field |
|
Add a user-defined list of values (LOV) field |
|
Add or edit a list of values (LOV) |
|
Update list of values (LOV) display criteria (Enabled/Disabled) (Start Date/End Date) |
|
Add or edit control display settings |
|
Make changes to reusable field |
|
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 |
|
Add a new user-defined field |
|
Set a field group field or a user-defined field as required |
|
Add or edit Groovy script |
|
Hide a field |
|
Add a user-defined list of values (LOV) field |
|
Update a user-defined list of values (LOV) |
|
Update list of values (LOV) display criteria (Enabled/Disabled) (Start Date/End Date) |
|
Control display settings |
|
Reusable custom fields |
|