In this article:
1. Business Rules to Use for Copying Card Properties between Linked Cards
2. How to Configure a Business Rule to Copy Card Properties between Linked Cards?
2.1 How to Use One Business Rule to Copy Card Properties
2.2 Copying custom fields and the “remove non-matching custom fields” option
2.3 Copying custom fields and the “add custom fields to board if missing” option
2.4 Copying comments or subtasks and the “remove extra comments/subtasks” options
2.4.1. The direction in which you would like to sync subtasks/comments
2.4.2. Behavior of business rules when creating/deleting subtasks/comments (with or without the 'remove extra subtasks/comments' option)
2.4.3. Editing subtasks behavior (with or without the 'remove extra subtasks' option)
2.5 Copying co-owners, stickers, and tags and the “only propagate changes made with this update” option
3. Situations When Those Business Rules Might Not Trigger
4. Practical Examples of Copying Card Properties via Business Rules
4.1 “Parent card is updated” rule
4.2 “Child card is updated” rule
4.3 “Relative card is updated” rule
4.4 "Predecessor card is updated" rule
4.5 “Successor card is updated” rule
1. Business Rules to Use for Copying Card Properties between Linked Cards
In order to copy card properties between linked cards, you have to use the “copy the values of these fields” action inside a Business Rule.
The “copy the values of these fields” option is available in the THEN part of the following business rules:
- Parent Card is Updated
- Child Card is Updated
- Relative Card is Updated
- Predecessor Card is Updated
- Successor Card is Updated
Note: The copy operation inside those business rules serves the purpose to also continuously synchronize the selected properties between two or more linked cards.
In other words, whenever a rule configuration is evaluated as TRUE (a certain condition is met), the rule can copy a property from one linked card to another and this can occur multiple times, in order to keep the two properties in sync.
2. How to Configure a Business Rule to Copy Card Properties between Linked Cards?
When configuring a business rule, you have the option to choose which properties of the linked cards should be copied from a trigger card/initiative onto a target card/initiative.
Such properties can be the standard card fields (e.g. owner, deadline, comments*, subtasks*, etc.), as well as card elements (e.g. custom fields, types, stickers, etc.).
How to Use One Business Rule to Copy Card Properties
You can also set up a single Business Rule that can copy card properties between linked cards on multiple different boards. To do this, you have to explicitly select the desired boards within the rule's AND configuration. You can then create a separate copy action for each property in case there are different properties that you would like to copy. Using the filters, you can configure whether or not a certain copy operation should trigger for specific types of cards and/or boards — refer to the image below for clarity.
Practical example
- (1) From the OR button, you can add as many boards as you want to the rule configuration.
- (2) From the “Add new copy values action” section, you can add and set up more copy actions for different boards.
If you want the rule to apply to ALL boards on the Businessmap account, you can remove the board filter from the AND configuration of the Business Rule. This can be useful when card links are used for the same types of actions across the account (e.g. using relative card links strictly for mirroring cards between boards).
The following warning will appear:
Important: Only Account Owners can create Business Rules that are applicable to all boards (i.e. without the "Board" filter).
Example with copying comments
When copying comments between linked cards, you have two options:
- (1) Add the comments from the source card to the destination card and preserve the old comments.
- (2) Remove any previous comments in the destination card and replace them with the ones from the source card.
Copying custom fields and the “remove non-matching custom fields” option
The “Custom Fields” option allows you to select which fields should be copied by the rule. You can select the desired fields from the “+” button (1). In addition, the "Custom Fields" section reveals three sub-options:
- Copy all custom fields (2)
- Remove non-matching custom fields (3)
- Add custom fields to board if missing (4)
You can use the “copy all custom fields” option to automatically select all custom fields from the trigger card to be copied into the target card. Along with that, you can enable the other option "remove non-matching custom fields" to achieve different results.
The idea behind this option is that you might want to unify the custom fields between two or more linked cards.
Example
As an example, let's say you have two linked relative cards on two different boards, and a total of 3 custom fields - fields 1 and 2 are added to the first card, while the second card has fields 2 and 3 on it. In other words, the only matching custom field for both cards is field 2.
If you would like to preserve the number of custom fields on each card, you would need to have the “remove non-matching custom fields” option disabled in the respective business rule (Relative card is updated). That way, whenever the rule is triggered, only field 2 will be synchronized between the two cards.
If, however, you would like to have an equal number of custom fields on both cards (so field 1 is removed from card 1 and field 3 is removed from card 2), you can enable the “remove non-matching custom fields” option. This would only sync the card's common field (field 2) and will remove fields 1 and 3 from both cards.
Copying custom fields and the “add custom fields to board if missing” option
This option can be useful if you have different numbers and types of custom fields across different boards, and you have linked cards across two or more boards.
If we use the same example as above where you have fields 1 and 2 added on one board, you might want to synchronize field 1 to board 2, even if this field has not yet been added to that board.
In that scenario, you can enable the "add custom fields to board if missing" in order to instruct the business rule to automatically add the missing custom field on the target board when attempting to sync it from card 1 to card 2.
If the option is disabled, the missing custom field will be ignored and will not be copied to the target card.
Note: The same option — “add to board if missing” — is available for other properties, such as:
- Block State (Blockers)
- Stickers
- Tags
- Types
Copying comments or subtasks and the “remove extra comments/subtasks” options
The rule configuration allows the user to select whether the extra comments or subtasks should be removed prior to copying the ones from the trigger card. This is disabled by default, and the system will therefore add the comments and subtasks from the trigger card into the target card and will preserve the old ones.
If enabled, any previous comments or subtasks in the target card will be wiped and replaced with the ones from the trigger card.
That being said, there are a few important things to be noted here:
1. The direction in which you would like to sync subtasks/comments
1.1 One-way sync
With a one-way sync, the business rule is executed only once — from the trigger card to the target card.
Example
Let's say you have 2 boards (A and B) and you want to copy the subtasks/comments from relative cards on board A to relative cards that are on board B, using the “Relative Card is Updated” rule.
This needs to be done by configuring the middle filter of the rule to only apply to board A (so whenever some change is made to the card on board A → copy the subtasks/comments from that card to the card on board B) and then explicitly configure the board B filter in the 3rd part of the rule (if relative card matches this filter).
Alternatively, you might have a 3rd board C, so if you skip the filter in the last part of the rule, the changes from board A would propagate to relative cards on both boards B and C.
The configuration of the rule above will only work in the A → B direction, i.e. if you make a change to the relative card on board B, the subtasks/comments from it will not be copied to the card on board A.
1.2- Two-way sync
With a two-way sync, the business rule is executed twice consequently — from the trigger card to the target card, which in turn makes the target card a trigger for the second execution of the rule.
Example
If you would like for the rule to work both ways, you would need to introduce board B in the middle part of the rule and remove the additional filter on the right side ("if relative card matches this filter" → board=B).
That way, changes you perform to either relative card will be pushed back to the other relative card(s). There might be other relative cards on other boards (board C) so this is why filters are important here - they allow you to specifically customize the rules so they only trigger on boards (or cards that match any other filters) where you need them to.
2. Behavior of business rules when creating/deleting subtasks/comments (with or without the 'remove extra subtasks/comments' option)
For the business rules logic, subtasks/comments are just a random string — there is no link between a subtask/comment on card A and a subtask/comment (with the same content) on card B.
Because of this, if you have subtasks 1,2, and 3 on cards A and B, deleting a subtask from the first card will not remove it on the second one, unless you have the “remove extra subtasks” option enabled.
How the “remove extra subtasks” option works
The "remove extra subtasks" option basically unifies the subtasks in both linked cards so enabling this would also delete the subtask on the second card, as the system checks the two cards' subtasks, sees that one of them has 1 subtask less (that matches the same string in the other card), and also removes that same subtask from the other card.
One-way vs. two-way sync
Here it should be noted in what direction you are using the business rule to sync the subtasks between the cards - if it is one direction only, whenever you delete a subtask from the first card (the trigger card), this would delete the subtask in the second card (the target card).
If, however, you have a two-directional rule, the same can happen if you perform the change (delete a subtask) on board B first. It is important to note which are the trigger and target cards as they will determine how the rule would function.
In other words, if you have an existing card on board A (target card) that already has 3 subtasks in it, and you have two-directional sync configured, and you link a card from board B (trigger card) (that does not have any subtasks) to the card on board A, and you have the "remove extra subtasks" option enabled, the subtasks on the target card will get removed as the rule unifies them on both sides.
In that case, the change was initiated by the trigger card (which does not have any subtasks), so this state will be pushed to the first card. For this purpose, we also recommend using that functionality with caution, as depending on the direction of sync and the trigger/target cards, you might end up with a loss of subtasks or comments on one of the two linked cards.
If you drag+drop a card (while holding down CTRL) on top of another card and choose the “link as relative” option, the card you are dragging would basically be the trigger card, so this is the direction in which the sync would occur. The same goes if you open the card's details and use the link function from there — this is the card, from which you initiate the link action, making it the trigger card.
3. Editing subtasks behavior (with or without the 'remove extra subtasks' option)
3.1 One-way sync
With a one-way sync, the business rule is executed only once — from the trigger card to the target card.
As mentioned above, there is no actual link between two subtasks in two linked cards. Due to this, if the "remove extra subtasks" is disabled, and if you edit a subtask in card A, the edited subtask will appear as a new subtask in card B (along with the one that was edited from the first card).
Now if you have the "remove extra subtasks" option enabled, and you edit an existing subtask on one of the cards, this will basically create a new subtask on the other relative card and will delete the other subtask (before the edit) in order to unify both subtasks' content on both cards.
3.2 Two-way sync
With a two-way sync, the business rule is executed twice consequently — from the trigger card to the target card, which in turn makes the target card a trigger for the second execution of the rule.
The behavior for two-way synchronization can be a bit confusing but, in a nutshell, this is what happens if:
- "Remove extra subtasks" is disabled:
Let's say you have 2 relative cards - if you create a subtask in the first one, it will be populated in the second card as well.
If you edit that subtask on either card, you are basically creating a new subtask in that card, which then gets copied to the other relative card - what you will end up in both cards is the first subtask (before it was edited) and the edited subtask since the sync is both ways, so the first card initially has 1 subtasks, then the edited one gets pushed to the second card in addition to the first subtask, then the 2 subtasks from the 2nd card are pushed back to the first card, unifying subtasks on both cards.
- "Remove extra subtasks" is enabled:
If you edit the subtask on the first card, this creates a new subtask in the other card, the system checks both cards for their subtasks' state and unifies them, which leaves both cards with the edited subtask only.
In conclusion, you would need to know:
- whether the sync should happen in one direction only or it should be multidirectional between multiple boards
- which are the trigger and target cards
- whether or not to utilize the "remove extra subtasks/comments" options
Copying co-owners, stickers, and tags and the “only propagate changes made with this update” option
When configuring a business rule to copy co-owners, stickers, or tags between linked cards, you have the ability to enable the “only propagate changes made with this update” option for those properties.
This option is particularly useful if you want to add or remove only certain co-owners, stickers, or tags to or from linked cards, instead of unifying those properties' values across the linked cards when the rule is executed.
Example
For example, let's say you have a ("Child card is updated") business rule that is configured to copy the co-owners from a child card onto its parent card whenever the co-owner property is updated on the child card.
Let's also assume that the parent card has multiple child cards, each of which could have multiple and different co-owners.
If the “only propagate changes made with this update” option for co-owners is not enabled in the rule configuration, and we set user John as a co-owner on one of the child cards, that change would be propagated to the parent card, so John would also be listed as a co-owner there.
If, however, we set Jane as co-owner on another child card linked to that same parent card, this action will basically override the existing co-owner (John) on the parent card and Jane will now be listed as the only co-owner. That might not be desirable, as we might want both John and Jane to be listed as co-owners on the parent card.
When the “only propagate changes made with this update” option for co-owners is enabled in the rule configuration, and we repeat the steps described above (set Jane as a co-owner on another child card), Jane will be added to the list of co-owners in addition to John (who was added as a co-owner on the parent card as a result of the change made on the first child card).
The “only propagate changes made with this update” option also works when removing co-owners, stickers, or tags from linked cards.
Let's say we have that same situation — a parent card that has John and Jane listed as co-owners, and a child card that has only John listed as a co-owner on it.
If we have that same business rule that is configured to copy (synchronize) co-owners between child cards and their parent, and the “only propagate changes made with this update” option is not enabled for co-owners, removing John as the co-owner from the child card will basically cause the parent to have the same co-owners i.e. none (both John and Jane will be removed from the co-owners list).
If the “only propagate changes made with this update” is enabled, and we remove John as a co-owner from the child card, this action will only remove John from the parent card, but Jane will remain listed as one of the co-owners.
The same behaviors described above will be applicable to stickers and tags.
In conclusion:
- If you would like for linked cards' co-owners, stickers, and tags properties to be identical, keep the “only propagate changes made with this update” option disabled.
- If you would like for linked cards to have different values on those properties depending on your needs and use case, enable the “only propagate changes made with this update” for some or all of the mentioned properties.
3. Situations When Those Business Rules Might Not Trigger
In some cases, the copy operation between two cards on different boards might fail if custom fields are configured to be copied, but the custom fields' configurations are different on the source/destination boards.
This can happen if:
- a custom field is not enabled on the destination board - this can be avoided using the "add custom fields to board if missing."
- a custom field has an empty value on the trigger card but has an enforced value on the destination card.
- the custom field on the destination card already has a value and it is immutable.
- a custom field that has different min/max values on the two boards.
- a custom field that has values, which must be unique across all boards.
- a custom field value that is not one of the allowed values on the destination card.
In addition, a rule might fail to copy a Custom Card ID if the value on the destination board must be unique but the Custom Card ID has already been used.
Similarly, a rule might fail if it is configured to copy stickers between cards but a limit on the usage of stickers has been reached on the destination board.
In those cases, the whole copy operation would fail which would also cause any other regular card fields, configured in the rule, to not be copied.
This will also send an email to the author (the user that created the rule) of the rule with a detailed explanation of what went wrong.
4. Practical Examples of Copying Card Properties via Business Rules
Business Rules can accommodate most scenarios and use cases, for example:
“Parent card is updated” rule
Whenever a child card is linked to the parent card, the rule can be used to copy all desired properties from the parent and also populate them on the child card. This can be achieved by either leaving the rule's default trigger as “any change” or explicitly choosing the “child card is added” trigger. This basically replaces the old functionality where the copying/syncing of properties was occurring upon the link action.
A typical example would be to update the color of the child card whenever the color of the parent card is changed.
“Child card is updated” rule
Using the previously available functionality, copying and synchronizing properties between a parent card and its child cards was one-directional only, i.e. from the parent on to the child. The "Child card is updated" rule now allows for the opposite scenario, i.e. you can copy a particular property's value from the child card onto its parent card.
A useful example would be to update the deadline of the parent card whenever the deadline of the child card has been changed and this should also be visible on the main project item.
“Relative card is updated” rule
A practical example would be to copy comments between two or more relative cards. This can be configured so that users can communicate through the comments in the relative cards. This means that the user commenting on the card on the Marketing board will also send a comment to the card on the Sales board, even if they are not a member of the board.
"Predecessor card is updated" rule
A practical example would be to copy all custom fields from the predecessor card into the successor card when the link is created. This can be used in cases when the custom fields have to be replicated on both of them.
“Successor card is updated” rule
A typical example would be to copy a specific custom field's value from the successor onto the predecessor. This can be used in cases when the custom field should only be specified after both cards have been completed but the field has to be replicated on both of them.