Run Calculate Attribute Rule when adding a relationship to a feature

[arcgis_janc]

I would like to run a calculate attribute rule when a new relationship is added to a feature. Attribute rules can now be executed, based on insert, update or delete. Adding a relationship to a feature does currently not trigger a calculate rule. I tried a calculate rule on the feature class (that has a relationship with a table) and on the table (that has a relationship with the feature class). It's strange the calculate rule on the table is not triggered when creating a new relationship. I would expect the update is triggered because the foreign key of the feature is added to the table record when creating a relationship, but Pro doesn't see this as an update ...

My suggestion/idea would be to add a fourth trigger (next to insert, update, delete), namely "change relationship". This will trigger an attribute rule whenever a relationship is added or deleted to a feature or table record.

[arcgis_janc]

I would like to run a calculate attribute rule when a new relationship is added to a feature. Attribute rules can now be executed, based on insert, update or delete. Adding a relationship to a feature does currently not trigger a calculate rule. I tried a calculate rule on the feature class (that has a relationship with a table) and on the table (that has a relationship with the feature class). It's strange the calculate rule on the table is not triggered when creating a new relationship. I would expect the update is triggered because the foreign key of the feature is added to the table record when creating a relationship, but Pro doesn't see this as an update ...

My suggestion/idea would be to add a fourth trigger (next to insert, update, delete), namely "change relationship". This will trigger an attribute rule whenever a relationship is added or deleted to a feature or table record.

[Sean_Haile]

It seems currently possible to apply the calculation attribute rule to the related table itself (triggered during insert/update/delete), which could then execute calculations back on the parent table. In the example below, the calculation rule is applied to the related table, and when there is an action performed on a record in the related table, its parent feature's validation status is automatically updated.

/*
Attribute Rule Name: Calculate Parent Feature Validation
Description: * Sets validationRequired on parent feature when a related table row is modified or deleted 
Subtype: All
Field: TRT_GUID //need to use a field otherwise it doesn't save
Editable: true
Error Number: 600
Error Message: Calc Parent Validation Failed
Triggers: UPDATE, DELETE
Exclude from client app eval: true
*/

var trtGuid = $feature.TRT_GUID
var fs = Filter((FeatureSetByName($datastore, 'TreatmentPT', ['GlobalID', 'TRT_GUID'], false)),'TRT_GUID = @trtGuid')
var f = First(fs)

if (f == null) {
    return trtGuid
}

//update className below to match fs name above
return {
   'validationRequired': 
       [
          {
              'className':"TreatmentPT",
              'globalIDs': [f.GlobalID]
           }
       ]
   }

But if you wanted to make changes to attributes in the parent feature instead, you could return them in the dictionary as an "edit" to the parent as shown in this example: 

https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/attribute-rule-dictionary-k...

I'm successfully using this strategy now to update parent validation status, haven't fully tested it out but seems to be working as I describe.

[arcgis_janc]

Hi Sean,

I understand that this works when you change an attribute in the related table record.

My issue is that the attribute rule is not triggered at the moment you assign a selected record to the relationship. Despites the foreign key is updated in the reletad table record at that moment, it doesn't trigger the attribute rule in my case.

I'm using Pro 2.9.6.

Is your attribute rule triggered when you assign a selected record to the relationship of the feature class?

[Sean_Haile]

Yes, the attribute rule (assigned to the related table) is triggered when the related record is initially inserted into the related table and the row is assigned its foreign key value from the parent feature. I set the attribute trigger to UPDATE, DELETE because I think on the initial insert of the related record it doesn't yet have the foreign key value assigned to the record.

[RalfSchmidt]

Hi @Sean_Haile,

We are facing the same issue as @arcgis_janc : The "update" attribute rule is not triggered when the foreign key is set using the context menu item "Add Selected To Relationship" from the "Attributes" dock pane. By contrast, if we establish the relationship by copying the parent's ID into child record using the table view, the attribute is triggered.

This behavior is on ArcGIS Pro 2.9.5.

We currently do not have any machine with ArcGIS Pro 3.x. Therefore two questions:

1) Do you establish the relationship by "Add Selected To Relationship" or by copy'n'pasting the ID?
2) What version of ArcGIS Pro do you use?

Ralf

[Sean_Haile]

Hi @RalfSchmidt ,

We are adding the new related records via "Add New to Relationship". Using Pro 2.9.5.

I think the important step to using either "Add New to Relationship" or "Add Selected to Relationship" is to have the attribute rule be triggered on UPDATE, DELETE, which is how my example above is configured. 

When you "Add New.." it seems like the behavior is it first adds the new row to the related table, then populates the foreign key value from the parent, which is treated like an UPDATE rather than an INSERT. If the rule is triggered on INSERT then the foreign key isn't yet populated, so it wouldn't find a corresponding record in the parent feature to update during execution of the attribute rule. If you used "Add Selected..." you'd be in the same situation, the record's foreign key is being assigned during an UPDATE action, so you want the attribute rule to fire off then, so that it can find its corresponding parent feature to update.

I also have "Exclude from application evaluation" checked, I don't know if that has any effect on this workflow, but thought I'd mention it here.

[RalfSchmidt]

Hi Sean,

Thanks  for your fast and extensive answer.

Yes, our rule is supposed to run in the UPDATE case and, yes, we are using "Add Selected To Relationship".

But I forgot to mention that our data is branch versioned and therefore, we have to edit the data using a feature service.

What kind of data do you have? Service, File Geodatabase, or Enterprise Geodatabase (= SDE)?

Ralf

[Sean_Haile]

Yes, our dataset is also branch versioned enabled, enterprise geodatabase 10.8.1 (sql server). Portal 10.9.1, editing occurs in Pro 2.9.5, using a feature service connection, editing a named version not default. The related record is in a table, related to a parent feature class. Primary/foreign key is a GUID field.

If you'd like to share your attribute rule, I might have some suggestions. Not an expert, but do have this working for me in our environment.

Sean

[RalfSchmidt]

In the last two years we developed a few dozens of attribute rules. Some of them are really fancy. But the test rule I have for this bug (or whatever it is) is really simple. It's connected to a field that simply get's a copy of a value of another field. The whole expression is like this: $feature.SOME_FIELD. So, not much room for doing mistakes here.

What's really strange: We are running the floors with this issue for month and you are the first person I had contact with where the attribute rule is triggered using "Add Selected To Relationship". But it looks like there are no significant differences between your and our case. I hope for ArcGIS Pro 3. Maybe it heals our problem.