Merge pull request #104927 from NuAlex/patch-57

Update concept-azure-ad-connect-sync-declarative-provisioning.md

Author: American-Dipper

articles/active-directory/hybrid/concept-azure-ad-connect-sync-declarative-provisioning.md

@@ -122,14 +122,20 @@ In *Out to AD - User Exchange hybrid* the following flow can be found:
 This expression should be read as: if the user mailbox is located in Azure AD, then flow the attribute from Azure AD to AD. If not, do not flow anything back to Active Directory. In this case, it would keep the existing value in AD.
 
 ### ImportedValue
-The function ImportedValue is different than all other functions since the attribute name must be enclosed in quotes rather than square brackets:  
+
+The function ImportedValue is different than all other functions since the attribute name must be enclosed in quotes rather than square brackets:
+
 `ImportedValue("proxyAddresses")`.
 
-Usually during synchronization an attribute uses the expected value, even if it hasn’t been exported yet or an error was received during export (“top of the tower”). An inbound synchronization assumes that an attribute that hasn’t yet reached a connected directory eventually reaches it. In some cases, it is important to only synchronize a value that has been confirmed by the connected directory (“hologram and delta import tower”).
+Inbound synchronization has a concept of assuming that an attribute that hasn’t yet reached a connected directory will eventually reach it at some point so, normally, synchronization gets an attribute value from the respective connector space, even if it hasn’t been yet exported or an error occurred during export. 
+In some cases, however, it is important to only synchronize a value that has been exported and confirmed during import from the connected directory. This function can be found in multiple “In From AD/AAD” out-of-box transformation rules where the attribute should only be synchronized when it has been confirmed that the value was exported successfully.
+
+An example of this function can be found in the out-of-box Synchronization Rule *In from AD – User Common from Exchange*, for ProxyAddresses attribute flow with Hybrid Exchange. E.g., when a user’s ProxyAddresses is added, the ImportedValue function will only return the new value after it has been confirmed from the following import step:
 
-An example of this function can be found in the out-of-box Synchronization Rule *In from AD – User Common from Exchange*. In Hybrid Exchange, the value added by Exchange online should only be synchronized when it has been confirmed that the value was exported successfully:  
 `proxyAddresses` <- `RemoveDuplicates(Trim(ImportedValue("proxyAddresses")))`
 
+This function is required when the target directory might change or discard an exported attribute value silently, and we want the synchronization to only process confirmed attribute values. 
+
 ## Precedence
 When several sync rules try to contribute the same attribute value to the target, the precedence value is used to determine the winner. The rule with highest precedence, lowest numeric value, is going to contribute the attribute in a conflict.
 
@@ -140,11 +146,9 @@ This ordering can be used to define more precise attribute flows for a small sub
 Precedence can be defined between Connectors. That allows Connectors with better data to contribute values first.
 
 ### Multiple objects from the same connector space
-If you have several objects in the same connector space joined to the same metaverse object, precedence must be adjusted. If several objects are in scope of the same sync rule, then the sync engine is not able to determine precedence. It is ambiguous which source object should contribute the value to the metaverse. This configuration is reported as ambiguous even if the attributes in the source have the same value.  
-![Diagram that shows multiple objects joined to the same mv object with a transparent red X overlay. ](./media/concept-azure-ad-connect-sync-declarative-provisioning/multiple1.png)  
+It is not possible to have several objects in the same connector space joined to the same metaverse object. This configuration is reported as ambiguous even if the attributes in the source have the same value.
 
-For this scenario, you need to change the scope of the sync rules so the source objects have different sync rules in scope. That allows you to define different precedence.  
-![Multiple objects joined to the same mv object](./media/concept-azure-ad-connect-sync-declarative-provisioning/multiple2.png)  
+![Diagram that shows multiple objects joined to the same mv object with a transparent red X overlay. ](./media/concept-azure-ad-connect-sync-declarative-provisioning/multiple1.png) 
 
 ## Next steps
 * Read more about the expression language in [Understanding Declarative Provisioning Expressions](concept-azure-ad-connect-sync-declarative-provisioning-expressions.md).