There is a problem with the external references dialog (right-click > References...) in DeltaV when using class-based modules. The results are potentially misleading by showing parameter shortcuts instead of parameter paths without following the norms for presenting parameter shortcuts of using "$" notation. 

BACKGROUND:

It is common to see DeltaV systems where programmers forget to update the default names of the parameter shortcuts when they modify their control module classes. You regularly see this scenario:

• module class has a embedded composite BLOCK1 with parameter LL_TRIP that has "allow instance value to be configured"
• programmer copies LL_TRIP to make a new parameter LL_TRIP1, but then renames it to HH_TRIP.
• Unless they fix the class, there is now a parameter shortcut BLOCK1$LL_TRIP1 that is pointing to BLOCK1/HH_TRIP.

It is also possible a company chooses to customize their parameter shortcuts as a design choice for their library. I have not seen it but I could understand reasons to do it.

The problem exists when you open the external references dialog of a class-based module, and in both the "Selected object" column as well as in the "Object" column you are presented with parameter shortcuts instead of (actual) parameters paths.

WHY IT IS A PROBLEM:

When you configure external references (external reference parameters or in expressions), you must use parameter paths, not shortcuts. (When did you last use a $ when configuring a reference?)

If you view and follow (select and click "open") any reference, you expect to find BLOCK1/LL_TRIP1 but will not find it. The only way to know that BLOCK1/LL_TRIP1 is BLOCK1/HH_TRIP is by viewing the module in DeltaV Explorer and matching the parameter shortcuts with their "Parameter Path", or by looking at the class (configure instance > parameters).

What makes it worse, is that Parameter shortcuts typically use $ versus a forward slash "/". When you view references, it will show (example): "THIS_MODULE/BLOCK1/LL_TRIP1", which may actually be the parameter shortcut "THIS_MODULE$BLOCK1$LL_TRIP1" with parameter path "THIS_MODULE/BLOCK1/HH_TRIP"

There is no place in this example where where "THIS_MODULE/BLOCK1/LL_TRIP1" is a valid object in the database. If you configure in explorer or use bulk edit, you have to use BLOCK1$LL_TRIP1. If you configure an external reference you have to use "THIS_MODULE/BLOCK1/HH_TRIP".

You could even run the risk in a situation like this:

1. "Hmm, does anything reference the boolean with status parameter "EBRAKE/NEVER_USE" of my module SPC_BALL_001?
2. Check references, (the list is long, sort by Selected Object, and scroll down alphabetically.) You don't see any References to that parameter (but there are many parameter references to BLOCK1/PARAM1 which you ignore, not realizing that is the same parameter) 
3. Delete the parameter from the class (turns out the module is class-based) and download the module(s)
4. Other referencing modules break on download, leading to a plant-wide trip, and a painful, drawn out recovery of the logic.

The above workflow is ok for a non-class-based configuration, but not sufficient for a class-based configuration. Extra steps needed:

• 1(b) Does the NEVER_USE parameter have "allow instance value to be configured" and does the parameter shortcut use the default name or a custom name? 
• 2(b) Search for the (potentially custom) parameter shortcut name if it has one, in this case BLOCK1/PARAM1, and find out that you have more work to do.
• 3 Update / manage all the references found before downloading.
• 4 Plant does not shutdown accidentally.

CONCLUSION:

At the bare minimum, if the External References dialog shows parameter shortcuts it should at least use the correct notation ('$' versus '/').

But do parameter shortcuts even belong in the External References Dialog?

I say not at all. Or perhaps only in addition to parameter paths, or only when in one direction ("shortcut uses path" or "path is used by shortcut", but never "shortcut is used by path/shortcut" or "path/shortcut uses shortcut")

The information presented is different depending on whether a referenced module is class-based or not, with no indication of which it is unless you open and examine each reference one by one.

Yes there are many ways to mitigate this with good practice and quality control, but I've seen messy class libraries at many different customer sites over the years as well as mixed databases containing classless and class-based modules working together.