Customization patterns

The customization pattern of an object is indicated in the Customization Pattern field found in most Nextworld objects.

An application can have multiple customization patterns available that can be applied to different records. For example, a record in the List Lookup Definitions application may use the Complete Lock pattern, which prevents users from making any changes to customized versions of that record. Another record in the application may use the Allow Additions pattern, which allows users to add more lookup keys to their customized record, but not edit any existing values.

Follow the links below to learn more about the Nextworld objects that have customization patterns:

Application customization

Considerations

Only Owned data items, or items you create, can be changed in a Customized application. Base data items cannot be updated. 

If you customize an application with the Allow Additions customization pattern, you can only add fields in custom rows. Each base row may have two custom rows. Custom rows, such as A Custom 01, display below the corresponding base row. For example, if you place a field in row B Custom 01, it displays immediately below row B. If both custom rows are used, they can be flipped in order, but they cannot be sorted away from their base row. Custom rows have the same Sort Sequence value as their base row, with either .1 or .2 appended to the end based.

Additionally, Base data items in an application cannot be added to any of the custom rows. 

Customization patterns

Application setting customization

Dashboard card customization

There are no customization patterns for dashboard cards. When a dashboard card is customized, you can only make changes to fields that hide a card on all dashboard pages.

Dashboard page customization

There are no customization patterns for dashboard pages. When a dashboard page is customized, you can only make changes to fields that hide a page, or make the dashboard page a global favorite. 

Data item customization

Considerations

If you customize a data item to add or update a Synonym, you don't need to generate the application to see the updated synonym in the application. 

Customization patterns

Endpoint definition customization

List lookup customization

Considerations

If you customize a list lookup, and then update a Lookup Description, you don't need to generate the application to see the updated Lookup Description in the application. 

Customization patterns

Logic block customization

Considerations

During implementation, decide whether a customer can add logic into the beginning or end of your logic block, or whether you want it completely locked. 

Customization patterns

Provide additional logic block prior to Insert, Update, or Delete Actions 

When creating an action block, or any other logic block that performs the basic table actions of insert, update, or delete, consider adding an additional logic block that is empty and has the Customization Pattern of AllowCustomBlock. This allows an easy way for partner's to add an extension or customer's to add a customization prior to inserting, updating, or deleting the data. This logic block would act as a pre-insert, pre-update, or pre-delete to the record and gives them the ability to alter the data or perform additional actions. An few examples of this can be found in the following:

• In the WriteDirectory logic block, an additional logic block called DirectoryPreInsertUpdateDelete was delivered in the base code. The DirectoryPreInsertUpdateDelete is delivered empty and has the Customization Pattern set to AllowCustomBlock. This logic block can be extended or customized and provides an easy way to alter the data prior to inserting, updating, or deleting the record. 
• In the WriteNettingTransactionJE logic block, an additional logic block called ExtendWriteNettingTransactionJE was delivered before calling WriteGLTransaction logic block. It's delivered empty and has the Customization Pattern set to AllowCustomBlock. This gives the ability to add additional JE lines before the GL API runs by extending or customizing the ExtendWriteNettingTransactionJE logic block.

Menu customization

There are no customization patterns for menu records. When a menu record is customized, you can only change the following fields:

• Application Setting Name
• Sequence
• Disabled

Restricted field customization

There are no customization patterns for restricted fields. When a restricted field is customized, only the Active field can be changed. While you can change a restricted field from inactive to active, you cannot change it from active to inactive. 

Roles customization

There are no customization patterns for roles. When a role is customized, only the Active field can be changed. This allows you make a role inactive in a delivered role hierarchy.

Table customization

Considerations

Only Owned data items, or items you create, can be added to a table. You cannot add Base data items to a Customized table.

Like other table types, summary tables can be customized and any fields added must be Owned. Any customization added added STFAsOfDataSources.STFDataSourceAlias need to be namespaced. Learn more in Metadata ownership and namespacing.

Customization patterns

Workflow restricted fields customization

Considerations

Customizing a workflow restricted field definition enables you to add any customized fields added to the workflow controlled application in downstream development. 

Customization patterns

Agent customization

Customization patterns

Automatic number and automatic format customization

Considerations

Changes to automatic number definitions can have unintended consequences in applications with existing records. 

You can only define an automatic format on numeric automatic number definition's if there is a value defined in the Automatic Format Field.

Customization patterns

The table below shows the customization patterns for automatic number definitions. 

Workflow customizations and subflows

Select the Customize row action on a workflow definition to create a customized definition. You can customize a workflow by making changes in the workflow definition, or by adding a subflow definition. 

Workflow definition customizations

This table describes the different customizations you can do in a workflow definition:

Subflow definition customizations

This table describes the different customizations you can do in a subflow definition:

Subflows can be added to both workflow definitions and inside of other subflows. Only transitions with the Allow Subflows checkbox selected in the parent definition may have subflows attached to them.

A transition path is the Base sequence of states a record must go through from start to finish. For example:

When you configure a subflow definition you can add steps in between the transition path's sequence of states, but you can't change the states or the order of the sequence they are in. For example:

 Learn more in Subflows and Subflow configuration.

Learn more about how to update a Customized workflow in the Customized workflow and base workflow updates and Configure customized workflow updates topics.

Customized workflow and base workflow updates

The Customization Status field in the list form of the Workflow Builder application shows a customized workflow's state in relation to the base version. The values of this field are automatically generated and are only used on customized workflows. Custom workflows with a Current status are up-to-date with the latest base version. When the Customization Status field shows an Update Available status, this indicates that a new base version exists for that workflow and you are able to begin a merge of your current customizations with the newest base version features.

You can continue to use your customized workflow version as your Active workflow without immediately updating the newest Base version, but you cannot make any additional changes to that custom workflow until the updates have been applied.

To update your workflow, you can create a draft of what your current customizations would look like when merged with the latest base version before you commit to the update. The workflow draft merge preserves your current, In-Active custom workflow while it creates an updated version that combines your current customizations with the newest base version features. When the draft merge is complete, you can review the updated version and mark it as your Active workflow if you are satisfied with the merge, or you can reject the draft merge and create a new customized workflow over the latest base workflow.

Draft merge process flow

The following diagram outlines the steps that make up a successful workflow draft merge process:

	Original version of objects.
	Updated version of objects.
	A customized workflow exists over a base workflow.
	The base workflow is automatically updated when a new version of the base workflow is released. The custom workflow does not receive any updates and remains the same as it was before.  The Customization Status field shows an Update Available status.
	You create a draft merge copy of the workflow to see how your current customization is merged with the new base version.
	You accept the draft merge workflow by marking it as your In-Active workflow which causes the older version to be archived.
	Archived version of object.

To configure your workflow update, see the Configure customized workflow updates topic. 

Configure customized workflow updates

Workflow Builder

In the Workflow Builder application, you must: 

• Select the Update row action on the custom workflow you want to merge with the newest base version. This creates a copy of the original workflow which is used to contain a drafted merge of the customized workflow and the newest base version. 
• Refresh the Workflow Builder application list form to see the copy of the custom workflow next to the custom workflow. The custom workflow retains its name while the copy is named <custom workflow name>UpdateInProgress.
• Open the <custom workflow name>UpdateInProgress workflow to review the changes made to the custom workflow when it was merged with the newest base version. 
• Select the Mark As Active row action if you are satisfied with the changes made in the draft merge workflow. This archives the original customized definition with the name <custom workflow name><current date>. This allows you to revert back to the old version of the customized workflow if you discover something wrong with the merge. You can delete the archive once you feel it is no longer necessary.
• If the merged workflow does not meet your requirements, you can delete it and make changes in the original custom workflow before attempting another merge. You can also create a new custom workflow over the newest base version and recreate the customizations you had before. 

The <custom workflow name>UpdateInProgress workflow name automatically changes to match the name of the base version it is customized off of and the definition changes to a Current status. This workflow is then moved into Active.

Subflows

A subflow definition consists of the transitions that you define to support your business processes, and where those transitions are configured to take effect within the parent workflow. The parent workflow can be a standard workflow definition, or another subflow. 

For example, a parent workflow definition could have the following transitions configured: 

Workflow Type	Transition Trigger	From State	From State Type	To State	To State Type	Allow Subflows
Supplier Invoice	Manual Transition	In Progress	Initial	Ready to Reconcile	Active
Supplier Invoice	Auto Transition	Ready to Reconcile	Active	Reconciled	Closed
Supplier Invoice	Auto Transition	Ready to Reconcile	Active	Error	Active
Supplier Invoice	Manual Transition	Error	Active	Ready to Reconcile	Active

You could create a subflow definition which has the following transition configured: 

The subflow definition can use different combinations of fields on the Subflow Configuration page to attach the subflow to different places in the parent workflow.

Subflow configuration

Configure the subflow

Open the Workflow Builder application from the Navigation Menu or within the Developer Studio. Identify the workflow definition where you want to add a subflow. To add a subflow definition, the workflow transition must have the Allow Subflows checkbox selected.

Create a new record in the Workflow Builder and select Subflow Definition. Then:

• Enter the parent workflow definition's name. 
• On the Subflow Configuration page, configure your subflow. You must have the To State and From State of the transition from the parent workflow which you want to insert your subflow definition between. 
• On the Transitions page, add detail lines for the transitions you want included in the subflow. 
  • Ensure one detail line uses the Exit Subflow To State Type. Records never exist in this state type, but it is necessary to include so the system know when the record should exit the subflow and continue in the base workflow definition transition path. 

Enable the subflow definition

Once a subflow definition has been created, it is not active until:

• The parent workflow definition has been customized by selecting the Customize row action.
• The subflow definition has been marked as Active. This can be done during subflow configuration. If the subflow definition was delivered, you must customize the subflow definition and select the Active checkbox. 

Control which records use subflow

To control which records in an application use the subflow definition, you can configure a decision definition in the Decision Builder application. Then, specify that decision definition in the Decision field of the subflow definition. 

For example, the Expense Reports application has a workflow definition enabled. If you wanted to add an approval to the workflow, you could create a subflow definition with an approval in it. If you wanted to specify that only expenses which exceed a certain dollar amount require the approval, you would create a decision definition which specifies the criteria for a record requiring the subflow be enabled. 

Learn more in Decisions.

Create or customize workflow restricted fields

Customize an existing workflow restricted field profile if you want to change or limit access to fields based on a workflow state which was delivered to you. This allows you to prevent users from making changes to tenant owned custom fields. Only definitions which have the AllowAdditions value selected in the Customization Pattern field are allowed to be customized. 

Create a new workflow restricted field profile if you need to create a new workflow state and limit access to the fields, or if your delivered workflow restricted field profile does not allow customization.

Customize a workflow restricted field profile

To customize a restricted field profile, in the Workflow Restricted Field Definitions application, you must:

• Open the definition. 
• In the Restricted Fields subtable, select the Add button to create an entry for each additional field that should be restricted. Only tenant owned fields can be added. 

Create a workflow restricted field profile

To create a new restricted field profile, in the Workflow Restricted Field Definitions application, you must:

• Create a new record.
• In the Restricted Fields subtable, select the Add button to create an entry for each field that should be restricted.
• In the WorkflowRestrictedFieldList.DataItemLookup field, select the name of the data item associated with the field.

In the Workflow Security application, you must:

• Create a new record. 
• Select the table the workflow is built over. 
• In the Access Rules subtable, enter the name of the restricted field definition.

Learn more in the Configure workflow security topic.

Metadata ownership and namespacing

The ownership of a metadata object can be:

• Base—These objects were created by Nextworld or a solution development partner. Base objects cannot be altered, but you may be able to customize or copy them.
• Customized—These are Base objects which have been customized in your environment. Customized objects share a connection with the base version. If a Base object changes as part of an upgrade, the customized object is also updated. You can customize a Base object with the Customize row action. Learn more in Customizations.
• Owned—These objects are yours and were created in your environment. You have complete control over these objects. 

Namespacing owned objects

Any metadata object you create includes a namespace automatically at the beginning of the objects identifying name. A namespace is a set of characters unique to your tenant that ensures that only one version of the object exists. Namespaces always begin with ns, and you cannot delete them.

For example, your organization's namespace might be nsCst. You might create a data item to track the storage temperature of an item, called nsCstStorageTemperature. If Nextworld later delivers a similar data item named StorageTemperature, the namespace ensures no conflicts exist between the two objects.

Some metadata objects, such as applications and tables, have a variety of configuration options. In some cases, a namespace is also applied to those configurations, such as pages you add to a customized application. In other cases, no namespace is applied to your addition. If Nextworld delivers an upgrade to a customized metadata object with an addition that has the same name as an addition you've added, Nextworld takes ownership over that object. You can still modify the object, but you cannot delete it.

For example, you can customize an application to add an application link. If Nextworld delivers an upgrade to the application with an application link that has the same name as the one you added, you can modify the application link, but you can't delete it.