What are you trying to accomplish? If you have two different instances of an item -- one in each of dataset A and B -- what value do you want copied to production? The one from A or B?
To say you want the value from A sometimes and B sometimes, what determines the sometimes and how can you have consistency in production when you have sometimes one value and other times the other value?
It is important to understand your use scenario as we allow defining a set of rules but not ones that switch back and forth.
Good to hear from you! The field holds the source system which last updated the record. If it is System A, then the field will reflect that it has been last updated by System A. I hope that clarifies the need for the field to be up-datable by both import data-sources.
So, the attribute is not really a configuration attribute but for tracking purposes. And, a good question is why does it matter which system has the item last updated a scanned copy on the discovery dataset? It doesn't affect the actual values of the attributes and it is really a random timing thing based on when data arrives from the different sources. If you ever needed to know that, looking at the source data will tell you when each was last updated.
Within the CMDB, there is no reliable way to accomplish what you are looking for. You could always try to have two different jobs, one with each side winning the precedence war. Then, run the right job. That has "your side" winning whenever it is updated. BUT, the challenge is what if something other than arriving data triggers a reconciliation run, then you cannot control which one will be the winner.
Or, you could create a filter that whenever an entry was updated that was not in the production dataset, it did a push fields operation to push the value of the source that was last update to all other entries with the same recon ID that were not in the production dataset (and was not yourself) -- or you could push NULL to all of them and use the "null doesn't win, use next system in order flag so that you get the right value. If doing this I would push the winning item just so I have that data everywhere. Then, you have the right value using normal processing of reconciliation and it works regardless of how reconciliation is performed.
So as far as i can understand you have defined one job with two source datasets. And the precedence values that you have written above show that the dataset A has higher precedence, and therefore the attribute has the same precedence value. This could be the case that because the attribute precedence is the same , the dataset precedence values is whats taken into consideration.
To resolve this you can try two methods.
1. Define two Jobs , one for each data source (Source dataset).
2. To define the same precedence for both. But i am guessing this wont be a feasible option because of other attributes.
If i am not understanding the issue correctly , can you please expand on this a bit more.