I'm trying to use @SecondaryTable, hoping to join from a foreign key on my p

... @Id
@GeneratedValue
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="domainValueTxt" type="xsd:int">
<xsd:annotation>
<xsd:appinfo source="appian.jpa">
@Column(table="LOOKUP_TABLE", name="DOMAIN_VALUE", insertable="false", updatable="false")
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

Continued from above...
@Id
@GeneratedValue
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="domainValueTxt" type="xsd:int">
<xsd:annotation>
<xsd:appinfo source="appian.jpa">
@Column(table="LOOKUP_TABLE", name="DOMAIN_VALUE", insertable="false", updatable="false")
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

@peterh, To my knowledge, @SecondaryTable can't be used for mapping non-primary key columns. And the reason why referencedColumn is ignored could be, when @SecondaryTable doesn't find any primary key join columns or a non-matching column (i.e. not the same column as Primary Key of the Primary Table), maps to primary key of the primary table. I think you have to go for a work around if you still want mappings to non-primary keys of the primary table.

I'll just add a clarification here for anyone who searches SecondaryTable and finds this post.

SecondaryTable is meant exclusively to join 2 tables where the secondary table has a column that matches the primary table's primary key column. The purpose is to be able to split tables with a large amount of columns into several tables, and then have them seamlessly join with SecondaryTable to make it look as if it is one big table with all the columns. It is not meant to join lookup or reference tables that map against specific non-primary key columns. That is why SecondaryTable doesn't have a parameter to configure which column to use from the primary table. It will only map against the primary key of the primary table.

For mapping lookup or reference data, you have to do a regular nested CDT even if it just has 2 fields (e.g. lookupId, lookupValue). That being said, the best practice is not to do nested CDTs for lookup data. It's better to just manage the lookup ID in the main CDT, and then use constants to get the lookup display value whenever there's a need to see the display value and not the lookup ID.

For displaying in a paging grid, helper CDTs might be necessary along with the updatearray function to switch the lookup ID with the display value.

As a final note, here's the JPA reference definition for SecondaryTable:
"The SecondaryTable annotation is used to specify a secondary table for the annotated entity class. Specifying one or more secondary tables indicates that the data for the entity class is stored across multiple tables."

After failing to get @SecondaryTable to work last year, I recently revisited it for another project in which I felt that it applied. I found Andre Dessens's comment very helpful because it made me realize that @SecondaryTable only applies to a very specific and limited use case: a single class/entity that is spread across multiple tables (see en.wikibooks.org/.../Tables. This means that the tables share the same key and are in a 1:1 relationship. I've been trying to use SecondaryTable when the relationship is actually N:1 e.g. the manager username for a particular user (see en.wikibooks.org/.../Tables

I recommend that Appian make this very clear in their documentation (see forum.appian.com/.../Create_Custom_Data_Types.html where the current example is misleading) and in their Advanced Data Design training course.