Share This:

Hi Everyone, Today we are going to discuss the final blog on business rules, As we all know the business rule is the never-ending topic so if you feel we need anything to add, please comment on the blog so we can improve or add the topics.

 

We used to get a lot of questions on How to setup Dynamic Linking data copy for tickets in FootPrints 12 from workspace A to workspace B. so let's find the below steps:

 

Example: Workspace A= IT Helpdesk, Workspace B=Pricing, We will create a ticket under IT helpdesk and then clicked on action tab> Copy> Select destination of the container i.e Pricing and then save. Now update a ticket of the IT helpdesk filed and that will be copied automatically on Pricing ticket.

In Workspace A

 

1. Create a "Related Tickets (Dynamic)" relationship in the item to be used. 

 

User-added image

 

2. Edit the item itself and select Fields.   A new checkbox/boolean field. "Updated by User" to identify a user edit will be needed.  The permissions will need to be Optional, but the field will not need to be added to the form.

3. Create the first after save business rule, "Set Flag Updated by User", in the item to check the "Updated by User" field whenever a user edits a ticket.  The following details are needed.

  • Trigger: After Save / On Update by User
  • Criteria: field Updated by User equal to [false]
  • Actions: Set field value: Set field value Updated by User to [true]

User-added image

 

 

In Workspace B

 

1. Create a "Related Tickets (Dynamic)" relationship in the item to be used. 

User-added image

2. Edit the item itself and select Fields.   A new checkbox/boolean field. "Updated by User" to identify a user edit will be needed.  The permissions will need to be Optional, but the field will not need to be added to the form.

 

3. Create the second after save business rule, "Dynamic Linking", that will run on the linked tickets and copy the user's changes. Also the action to Copy all Fields From Linked only copies data for the fields with the same name and data types.

  • Trigger: On Linked Item Update : [ Related Tickets (Dynamic) : Related Ticket ]
  • Criteria:
    field: Generic Linking Any [ Related Tickets (Dynamic): Related Ticket ]
    field: Updated by User equal to [ true ]
  • Actions:
    Set field value: Set field value Copy all fields from linked
    Set field value: Set field value Updated by User to [false]

 

User-added image

 

Note: Save each rule, then Save & Publish Both workspaces.

Tips and tricks for Business rules:

Generic linking conditions

The following conditions are available for Generic Linking type rules:

  • Any
  • Every
  • Participates-in

 

For the Any and Every condition, operators are selected for applicable fields. "Participate in" means if there is a link to a subtask or another item type, apply the rule.

Make sure to set the trigger to run when a specific update occurs.

Defining rules to execute an external action:

You can define rules to run an executable program or script and perform other actions external to FootPrints—actions that you can also reach from a command prompt. The action simply runs the specified program or script; it does not automatically interact with the operating system’s command interpreter or shell.

 

If the action that you want to be performed requires a command interpreter (for example, to run an operating system command or redirect standard input/output), the action must explicitly call the appropriate command interpreter for your operating system (for example, cmd or command for Windows or sh for Linux).

 

An example of an external action that requires a command  interpreter: cmd /c “ipconfig > ipconfig.txt”. . (Full paths were omitted here for brevity.)

An example of an external action that does not require a command interpreter is: myprogram.exe.

 

NEVER delete Workflow business rule from the business rule:

 

We have seen lots of customers deleting workflow business rules from the Business rules section instead of workflow-business rules. This causes an issue while publishing workspace as a business will not completely remove. We always recommend customers if they want to remove any rule from workflow then it should be from the workflow business section only.

 

Renamed or deleted fields cause errors:

If you rename or delete a field used in a business rule, errors are generated when you next publish the container that includes that rule. To correct this error, you must modify the part of the rule that included the "missing" field. You can select the correct field (if the field was renamed) or remove the statement that refers to the field (in either case).

 

Thanks for reading the article. Please rate the blog and add comments to share your experiences.