# Account Updated Event Trigger Reliability for Source Account Attribute Changes

**URL:** <https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397>\
**Category:** SHF Discussion and Questions\
**Tags:** workflows, event-triggers, aggregation, sailpoint-identity-security, connectors, provisioning, apis\
**Created:** [July 14, 2026, 5:41am UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397 "2026-07-14T05:41:27Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![lalithajay](https://avatars.discourse-cdn.com/v4/letter/l/96bed5/32.png) [@lalithajay](https://developer.sailpoint.com/discuss/u/lalithajay)\
**Post date:** [July 14, 2026, 5:41am UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/1 "2026-07-14T05:41:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\
**Post date:** [July 14, 2026, 6:56am UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/2 "2026-07-14T06:56:50Z")

</div>

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

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

```

If AttributeX is normally changed directly on the target system, [Native Change Account Updated](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/native-change-account-updated/) with [Native Change Detection](https://documentation.sailpoint.com/saas/help/sources/native_change_detection.html) 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.

---

<div class="post-metadata">

**Author:** ![lalithajay](https://avatars.discourse-cdn.com/v4/letter/l/96bed5/32.png) [@lalithajay](https://developer.sailpoint.com/discuss/u/lalithajay)\
**Post date:** [July 14, 2026, 7:44am UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/3 "2026-07-14T07:44:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\
**Post date:** [July 14, 2026, 9:07am UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/4 "2026-07-14T09:07:37Z")

</div>

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](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/account-updated/) 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.

---

<div class="post-metadata">

**Author:** ![lalithajay](https://avatars.discourse-cdn.com/v4/letter/l/96bed5/32.png) [@lalithajay](https://developer.sailpoint.com/discuss/u/lalithajay)\
**Post date:** [July 14, 2026, 1:34pm UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/5 "2026-07-14T13:34:46Z")

</div>

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.

> **[Identity Attributes Changed | SailPoint Developer Community](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/identity-attribute-changed/)**
>
> Fires after one or more identity attributes changed.

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,

---

<div class="post-metadata">

**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\
**Post date:** [July 14, 2026, 2:17pm UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/6 "2026-07-14T14:17:09Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lalithajay](https://avatars.discourse-cdn.com/v4/letter/l/96bed5/32.png) [@lalithajay](https://developer.sailpoint.com/discuss/u/lalithajay)\
**Post date:** [July 14, 2026, 11:35pm UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/7 "2026-07-14T23:35:39Z")

</div>

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:

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

```

I also noticed that the it also contains:

```auto
"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:

```auto
"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.

---

<div class="post-metadata">

**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\
**Post date:** [July 16, 2026, 11:11pm UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/8 "2026-07-16T23:11:34Z")

</div>

Interesting… so from what I understand and can see in the [trigger docs](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/account-updated), `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](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/identity-attribute-changed) may still be the more reliable option based on your testing.

---

<div class="post-metadata">

**Author:** ![lalithajay](https://avatars.discourse-cdn.com/v4/letter/l/96bed5/32.png) [@lalithajay](https://developer.sailpoint.com/discuss/u/lalithajay)\
**Post date:** [July 20, 2026, 1:33am UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/9 "2026-07-20T01:33:17Z")

</div>

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:

> **[Account Updated | SailPoint Developer Community](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/account-updated/)**
>
> Fires after an account is updated.

I currently have the following filter defined:

```auto
$.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:

```auto
"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.

---

<div class="post-metadata">

**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\
**Post date:** [July 20, 2026, 2:06am UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/10 "2026-07-20T02:06:42Z")

</div>

Hi Lalitha. Yes, the current filter may explain the unnecessary executions. SailPoint’s [filtering docs](https://developer.sailpoint.com/docs/extensibility/event-triggers/filtering-events) 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](https://developer.sailpoint.com/tools/json-path-evaluator), and then validate it using [`POST /beta/trigger-subscriptions/validate-filter`](https://developer.sailpoint.com/docs/api/beta/test-subscription-filter) before updating the subscription.

---

<div class="post-metadata">

**Author:** ![lalithajay](https://avatars.discourse-cdn.com/v4/letter/l/96bed5/32.png) [@lalithajay](https://developer.sailpoint.com/discuss/u/lalithajay)\
**Post date:** [July 20, 2026, 2:54am UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/11 "2026-07-20T02:54:57Z")

</div>

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

> **[Filtering events | SailPoint Developer Community](https://developer.sailpoint.com/docs/extensibility/event-triggers/filtering-events/)**
>
> Many triggers can produce a staggering amount of events if left unfiltered. Event filtering helps you solve this problem.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\
**Post date:** [September 18, 2026, 2:55am UTC](https://developer.sailpoint.com/discuss/t/account-updated-event-trigger-reliability-for-source-account-attribute-changes/216397/12 "2026-09-18T02:55:54Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.