How to name map for common objects but has different parent - for reusablity

It's unclear which option you tried.  Could you clarify?

Also, successful mapping is half the problem.  You noted that you are also having problems identifying the object while the test is running.  This could be something that is not a mapping problem but a problem in timing.  Make sure you have appropriate wait methods and other such things in place to make sure you're giving sufficient time for the popup to display before you proceed.

Re Conditional Mapping:  It is not the criteria for SelectSettingdialog that you change.  Rather it is the criteria for its *parent* that you change.  So rather than having a namemap like this:

Revera_AnalysisMain_DiagnosticUtility

->SelectSettingsDialog

Revera_OperatorInterface

->SelectSettingsDialog

You'd have a namemap like this:

Revera_Common

->SelectSettingsDialog

The namemap criteria for Revera_Common might look something like this:

WndCaption = "DiagnosticUtility" OR WndCaption = "OperatorInterface"

When you moved the objects under Sys, did you set the "Extended Find" flag to true?   This is necessary in order to allow TC to find the object.

However, if they are in different applications, than I'm not sure even that would work.  What I would suggest then, if you want to interact with the dialog regardless of application, is write some custom routine that will take, as a parameter, the Aliased object that corresponds to the dialog in the application and then just implement it that way.  Here's some sample code that demonstrates what I mean, assuming you have two objects that are the same but in different applications:

//Objects to work with

Aliases.MyApp1.dialogWindow
Aliases.MyApp2.dialogWindow

//Map any child objects of those two objects using the exact same naming and 
//hierarchal structure.  Say each window has a text box, an OK button, and 
//a Cancel button  So, I'd create a function to fill in the text box and click OK

function addTextToDialog(dialogWindowObject, textString) {
    dialogWindowObject.textboxEdit.Keys(textString);
    dialogWindowObject.buttonOK.ClickButton();
}

//And another function to just click Cancel on the dialog

function cancelDialog(dialogWindowObject) {
    dialogWindowObject.buttonCancel.ClickButton();
}

This way you can have standardized code for working with your dialog window that will work regardless of which application it belongs to.  It will take some discipline to make sure you map the dialog the same in both locations, but this works pretty well for us.  A bonus is then that, if you have other objects that have a similar mapping (textboxEdit, buttonOK, buttonCancel), you could use these functions for multiple purposes not just limited to the original dialog windows.