Quest ODM AD has many building blocks: Environments, Workflows, attribute Templates and more. How do they relate to each other, and how does the product decide which attributes to use during Read / Write operations?
The Environment in Quest ODM AD defines a certain directory containing objects, for example, on-prem AD Forest (Domain) or cloud Entra ID. When setting it up, you can “carve out” a single Domain out of the multi-domain forest, a single OU within the Domain and so on. Then, with the filter put on top of it, it defines what objects the product will read and place into the Quest ODM cloud metaverse (SQL-based storage). Note that you can create multiple Environments which point to the same single AD forest or Entra ID, for example, 5 Environments each pointing to a unique OU in the on-prem AD Domain, each having unique filter for Entra ID objects and so on.
You then create a Workflow, which tells the product what operations it takes with these Environments: Read objects per the scope already defined in the Environment (Source), Manipulate object attributes according to certain Rules defined in the Template, and then Write into another Environment (Target).
We already had to use the word “Template” in the paragraph above. It is a set of Rules which define what you intend to do with objects and attributes: Create or Not Objects, Sync or Not SIDHistory, Copy OR Not certain Attributes, and Modify those attributes. This is basically an attribute mapping template.
If you only have Read and Match Workflows, Quest ODM AD has a default set of attributes which it reads. These attributes are defined internally in the Quest backend. Once you create a Template containing more attributes and associate (!) it with the Stage and Write Workflow, those additional attributes are also added to the list. Therefore, if you need to read certain attributes, simply create a Template and associate it with the Workflow that never runs, for example: Do not assign any schedule, keep it in Test Mode, add a Staging Filter which does not apply to any objects and so on. And of course, any attributes that are part of the Template used in the actual Running Stage and write workflow will be included/placed into the Quest ODM database and added to each object. If the same attribute appears on multiple templates, then it will just be taken into account once.
Per the latest product improvements, a new “Used Attributes” Tab is being added to the Environment screen to capture all such attributes that’s being Read or Not, making it easier to tell one from the other.
