Hey @ajj,

If I get it right, you can copy the objects from one board and paste them onto the other. Or you can duplicate the board and work with the copy.

Not quite sure what you mean speaking about “Priority, Weight, etc.” Can you please describe your use case in more detail? 

Thanks for the reply Marina. I like to link two or more boards and some of their “objects”, or tickets, … (I am not sure what they are called) and as one updates the other also updates. 

For example, let’s say there is a sticky note, or a “card” that I can given some attributes to it. One of the attributes I like to be able to give it is the priority of the card -  Let’s say these are “tasks”.  So, I have Critical, Highest, High, Medium, .. priorities. And, let’s say this card is in two boards. Then, if I update one in one board, how do i set it up so it updates in the other board as well. 

I see what you mean, @ajj. I’m afraid it doesn’t work the exact way you describe. 
The functionality you mention reminds me of Jira Cards integration (available for paid plans only). With this integration you can work with Jira issues right on the board - when you change the status of a card in Jira, it is updated on the board where the card is embedded.

Hope that helps 

@Marina 
You are correct it doesn’t work that way.. however it is critical functionality to consider.

If you are hoping Miro will scale with larger teams for complex developments where teams may reference a design or set of directives that are evolving from another team and they need to adapt with it. Copying in an update from a different board is unfeasible. 

Being able to define a container asset that is then placed in many boards. Then to place contents in that container that you would need to maintain reference to as it updates is a very very useful function. 

If you want simple examples its instancing classes in code.. we don't copy code around between places we want to use it, we create classes and then instances and then call the functionality or overload. A better specific example is a Singleton pattern. We create a source of which there can be only one then we update the source and all usages of it are guaranteed to be referencing the exact same functionality. 

Food for thought!