Account Updated Event Trigger Reliability for Source Account Attribute Changes

Identity Security Cloud (ISC) ISC Discussion and Questions
, , , , , ,
1

Hi Team,

I thought it would be better to raise this as a new topic.

I’m planning to use the 'Account Updated’ event trigger, but I’m finding its behaviour to be inconsistent, as it doesn’t always fire when I expect it to.

My use case is based on a source account attribute (let’s call it AttributeX). This attribute is not mapped as an identity attribute in the Identity Profile. My event trigger filter is configured to invoke another service when AttributeX changes from “ABC” to “PQR”, which seems to be the expected configuration for this trigger.

However, the trigger does not fire consistently. To test, I’m updating the account attribute via the SailPoint API (using Postman). Sometimes the trigger fires on the first update, but subsequent updates are inconsistent. In some cases, the event doesn’t fire at all, even though the attribute value has changed.

Are there any additional prerequisites or conditions that must be be met for the Account Updated event trigger to fire reliably? For example:

  • Does the account update need to occur through a specific SailPoint process?

  • Are there any known limitations when the updated attribute is not mapped to an identity attribute?

  • Is there any event deduplication, batching, or aggregation behaviour that could explain this?

My concern is that the trigger doesn’t appear to behave consistently or in real time, making it difficult to rely on for this use case.

By comparison, the Identity Attributes Changed event trigger appears to be much more reliable. When I update an identity attribute via the SailPoint API (again, for testing), the trigger fires consistently.

I do have the option of exposing AttributeX as an identity attribute, since it originates from a trusted source account. However, I’d prefer to avoid doing that if possible, as I don’t believe the attribute needs to be part of the identity profile solely to support this event.

Has anyone experienced similar behaviour with the Account Updated event trigger, or can shed some light on why this might be happening and the recommended way forward?

Thanks in advance.

2

Hello Lalitha, I think the inconsistency may be related to how the change is being tested. The account update APIs support changing normal account attributes only for flat-file sources, and the PUT endpoint runs asynchronously, so the value may not be updated yet when the next test is performed. It may help to confirm the updated value using GET /accounts/{id} before repeating the test.

You should not need to map AttributeX to the Identity Profile for this. The Account Updated trigger works at the account level, and the filter can target the change directly

$.singleValueAttributeChanges[?(@.name == "AttributeX" && @.oldValue == "ABC" && @.newValue == "PQR")]

If AttributeX is normally changed directly on the target system, Native Change Account Updated with Native Change Detection enabled may be a better fit.

If the account value is confirmed as changed after the update or aggregation completes, but the trigger still does not fire, I would open a case with SailPoint Support.

3

Hi @punna0001

Thanks for your reply

After updating the account using POST via Postman (not PUT), I can immediately see the updated value both in the UI and when retrieving the account using GET /accounts/{id}. However, I don’t see the Account Updated event being triggered. It only fired once during my testing, and on that occasion I was able to see the $.singleValueAttributeChanges payload, which was exactly what I was looking for.

To clarify, AttributeX is a source (trusted) account attribute and is not being modified directly on the target system.

Given that the event did fire once, and based on the information above, do you see any issue with using POST for these updates? It appears to work correctly for updating the account via Postman (for testing purposes), so I’m wondering whether the HTTP method itself could be contributing to the inconsistent event behaviour.

As mentioned previously, the Identity Attributes Changed event trigger behaves consistently under similar testing conditions.

4

The POST /accounts endpoint can update an existing account record when the account ID is included, but I would not rely on it for testing the Account Updated trigger. It writes the data to ISC directly (which is why you see it in the UI right away), but the Account Updated trigger is designed to fire when changes come through aggregation or provisioning. So the POST update may not always go through the same event processing path. The fact that it fired once tells me your filter and payload are probably fine.

Since AttributeX comes from the trusted source, I would suggest changing the value in the source data and running an account aggregation. That should produce a proper event with cause AGGREGATION and would be closer to how it will work in production.

If it still behaves inconsistently through aggregation, then I think a SailPoint Support case would be the right next step.

5

Thanks @punna0001 for your reply

Yes, the accountId is included in the payload along with the attributes, so the POST /accounts endpoint works as expected.

I tend to agree that this behaviour is likely because the update is not occurring through the conventional account aggregation process. However, it is still a bit of a mystery why the Account Updated event fired once when the update was performed through the API.

On another note, in our environment we use both regular account aggregations and API-based dynamic account updates to support a faster joiner process. It would have been ideal if the Account Updated event trigger also worked reliably in this API-driven scenario. That said, if this is the intended design, then I understand there isn’t much that can be done.

What surprises me is that the Identity Attributes Changed event trigger appears to behave differently. Although the documentation states that it fires when identity attributes change as a result of account aggregation, it consistently fires when I update the identity attribute through the API during my testing. My assumption is that it detects the change during the identity attribute update process rather than relying solely on aggregation.

Given our requirement for API-driven dynamic updates, it looks like the only practical option is to expose this trusted source account attribute as an identity attribute.

The reason is that, in our environment, the API may update the account before the next aggregation runs. When the aggregation eventually executes, it may not detect any change, meaning the Account Updated event would never be generated.

Regards,

6

Yes, that makes sense. If you get any clarity on why the POST update triggered the event that one time, I would be interested to know as well. That part is still unclear from the documentation.

7

Hi @punna0001

When the one-off event occurred, I captured the activity log payload. Interestingly, it contains the following section, even though no scheduled account aggregation had taken place at that time:

"event": {
  "cause": "AGGREGATION",
  "type": "ACCOUNT_UPDATED"
},
"accountChangeTypes": [
  "ATTRIBUTES_CHANGED"
]

I also noticed that the it also contains:

"origin": null,
"name": "AAAABBBB"

However, when I compare this with other ACCOUNT_UPDATED events in the Activity Log, I see the following instead in addition to same cause like above:

"origin": "AGGREGATED"

I’m trying to understand the distinction between these two cases.

  • What does "origin": null indicate?

  • What does "origin": "AGGREGATED" indicate?

  • More specifically, why would the event cause be reported as "AGGREGATION" while the account origin is null?

Any insight into how these fields are populated and what drives the difference would be greatly appreciated.

8

Interesting… so from what I understand and can see in the trigger docs, event.cause and account.origin are describing different things. origin: "AGGREGATED" means the account is identified as having originated through aggregation. origin: null means no origin value was provided for that account in the trigger payload.

event.cause: "AGGREGATION" appears to indicate the process that generated that specific event. Since the Account Updated trigger can be generated through aggregation or provisioning, this does not necessarily conflict with the separate origin value being null.

I could not find any official documentation explaining exactly when origin is populated, especially for updates made through POST /accounts. You could check the account using GET /accounts/{id}. If origin is null there too, it is not populated on the account record. If GET shows AGGREGATED but the trigger payload showed null, I would raise it with SailPoint Support as a possible payload inconsistency.

For your API-driven flow, using Identity Attributes Changed may still be the more reliable option based on your testing.

9

Hi @punna0001

After further testing, I have a doubt the reason for misfiring is the filter I have so

specifically the Event Trigger Filtering capability, and I am trying to create a combined filter to prevent unnecessary event executions.

For the Account Updated trigger:

I currently have the following filter defined:

$.singleValueAttributeChanges[?(@.name == "compstatus" && @.newValue == "PREHIRE")]

This successfully filters events where the compstatus attribute changes to PREHIRE. Now

However, I would also like to enhance the same filter by adding an additional condition using && to validate the LifeCycleStateAtt attribute (for example, value XYZ), which exists in a different section of the payload:

"account": {
    "attributes": {
        "LifeCycleStateAtt": "XYZ"
    }
}

From my testing, it appears that combining conditions using && does not work when the attributes are located in different elements of the payload.

Could you please advise if there is a recommended way to construct a combined filter that evaluates both:

  • singleValueAttributeChanges → compstatus changed to PREHIRE

  • account.attributes.LifeCycleStateAtt → value is XYZ

The goal is to ensure the event only fires when both conditions are satisfied and avoid unnecessary event processing.

Thanks.

10

Hi Lalitha. Yes, the current filter may explain the unnecessary executions. SailPoint’s filtering docs mention that && can only be used when both conditions are part of the same item. Since compstatus is inside singleValueAttributeChanges and LifeCycleStateAtt is under account.attributes, they cannot be combined directly in the same && expression.

You could try chaining the two filters like this:

$[?($.account.attributes.LifeCycleStateAtt == "XYZ")].singleValueAttributeChanges[?(@.name == "compstatus" && @.newValue == "PREHIRE")]

This first checks whether the account’s current LifeCycleStateAtt is XYZ, and then checks whether compstatus changed to PREHIRE.

I would test it with both matching and non-matching payloads in SailPoint’s JSONPath Evaluator, and then validate it using POST /beta/trigger-subscriptions/validate-filter before updating the subscription.

11

Thanks @punna0001

perfectly working fine with your suggestion,

in nutshell, still using POSTMAN API but Account Update fires with above filter,

The chaining feature is quite handy and really beneficial some reference stated here in same place