Privileged Account Extend Searchable Properties

this update extends how privileged accounts can be queried in scripts by allowing additional searchable properties to be defined via sql joins, similar to how joins/common properties can be exposed for services and assets the main use case is being able to search privileged accounts by owner (and other fields), even when those fields are not directly available in the v privilegedaccount view overview previously, when you loaded a privilegedaccountcollection and called loadquery( ), filters could only target columns exposed by the v privilegedaccount view this limited searching to whatever that view surfaced with this feature, you can define one or more joins and expose additional properties (for filtering and selection) by adding an xml join definition to the privileged accounts root object this change does not alter existing queries it only adds the ability to expose additional queryable properties when join definitions are configured what changes for developers you can now keep using privilegedaccountcollection loadquery( ) filter using additional properties (for example, owner) extend later with more joins/properties without changing script logic example (existing pattern remains the same) using system; using system data; using innovation activate; class script scriptbase { public void main() { privilegedaccountcollection accounts = new privilegedaccountcollection(null); privilegedaccount root = evaluator getobject("=/resources/privileged accounts/administrator account") as privilegedaccount; accounts loadquery(root, "{owner} = 'owner\@example com'"); foreach (privilegedaccount account in accounts) trace writeline(account path); } } configuration to expose additional fields, add an xml definition to the privileged accounts root object to define the required joins and mapped properties join definition example \<root> \<join to="left outer join approver a on a guid = s guid and endtime is null"> \</join> \<join to="left outer join adcache ad on ad guid = a approverguid"> \<property name="owner">ad mail\</property> \</join> \</root> how it works each \<join> element appends a join to the query a \<property> maps a friendly property name (used in filters) to a sql expression/column in the example above the query joins from the privileged account record to approver, then to adcache the exposed property owner is mapped to ad mail property values must align with what your scripts supply in filters for example, if owner is mapped to ad mail, your filter should compare against an email address if you want to filter by guid instead, map owner to the appropriate guid column querying with exposed properties once configured, you can filter using the new property name in loadquery( ) example patterns accounts loadquery(root, "{owner} = 'user\@example com'"); accounts loadquery(root, "{owner} like '%@example com'"); use the same filter syntax you already use elsewhere in activate collection queries the key difference is that the property must be defined in the join xml to be queryable common use cases search privileged accounts by owner add joins that resolve the owner to a stable identifier (guid, email, username) expose it as {owner} filter in scripts using {owner} = extend for additional fields later you can add more \<property> mappings (and supporting joins) over time, for example owner display name owner guid request/approval state metadata source directory attributes troubleshooting “invalid column/property” or property not recognised confirm the \<property name=" "> \</property> is present in the join xml confirm the property name in your query matches exactly (case and spacing) confirm the sql column/expression referenced by the property exists in the join scope filters return no results validate what the property is mapped to (for example, ad mail vs ad guid) ensure your filter value matches the mapped data type and format check join conditions (for example, the endtime is null clause may exclude expected rows) performance concerns prefer targeted joins and indexed columns (guids often perform better than free text mail fields) avoid adding unnecessary joins if you only need one or two properties notes for implementation keep property names stable (owner, ownerguid, etc ) so scripts don’t need frequent updates if you need to support multiple identifier types (email + guid), expose multiple properties rather than overloading one