Delta Aggregation on Web Services SaaS Connector

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

Hi All

Having an issue with enabling Account Delta Aggregation on the Web Services SaaS Connector.

Documentation says that it is a supported feature and specifically here indicates that $application.lastAggregationDate_account$ holds the last successful aggregation timestamp, but I can not get that placeholder to be replaced within the context URL for the Delta Account Aggregation HTTP operation.

Based on that naming convention, I would expect to see that attribute in the Source attributes, but itā€™s not there.

Looking at the logs, I can see a ā€˜stateā€™ parameter getting passed as input to the aggregation "state": {"lastAggregationDate_account": "2026-01-16T10:31:49Z"}, so Iā€™m sure itā€™s getting saved somewhere, but Iā€™m not aware of how to get that value into a context url.

Has anyone successfully enabled Delta Aggregation on the SaaS Web Services Connector by using a variable in the context URL?

2

Hi Jeremy, probably not your issue but throwing it out there in case. Have you already run a full aggregation at least once?

1 Like
3

Thanks Margo. Yes, full aggregation was run successfully prior to the attempted delta.

4

So I had something similar happen with the VA-based version of the Web Services connector. Not sure if this applies the SaaS version or your situation. My issue was that I was in early development stages so I just playing around trying to get it to work and I didnā€™t have the response mappings setup yet on the Delta Aggregation operation, so the connector was falling back to the regular Account Aggregation operation.

5

Thanks Patrick, but I can see from the logs that it is actually making the delta call with the unresolved variable $application.lastAggregationDate_account$

6

Could be a bug with SaaS version. A lot of SaaS connectors are just wrappers around the Java based VA type connectors, so maybe itā€™s not passing that delta property properly. Not sure.

7

Thatā€™s sort of what Iā€™m thinking, so hoping to find out if anyone has made it work

8

Chiming in here and running into the same problem. The only way it can ā€œworkā€ but not update is if I set that value manually via API:

[

  {

"op": "add",

"path": "/connectorAttributes/lastAggregationDate_account",

"value": "2026-02-15T01:53:15Z"

  }

]

And sadly after the delta aggregation completes, the value is not updated. Feels like a bug and the only way to work around this is to do a before cloud rule I imagine.

9

Thanks @dominics Iā€™ve raised a case with SP Support, will let you know how I get on.

10

I verified that the $application.lastAggregationDate_account$ attribute works in the URL for both VA-based and SaaS versions.

However, after examining the source configuration (using VSCode), I noticed a structural difference between the two:

  • In the VA-based version, there is a lastAggregationDate_account attribute directly inside connectorAttributes.

  • In the SaaS version, instead of that attribute, there is ONLY a deltaAggregation object inside connectorAttributes.

In VA version, it looks like this:

"lastAggregationDate_account": "2026-02-19T12:27:09Z"

In the SaaS version, it looks like this:

"deltaAggregation": {
    "std:entitlement:list": null,
    "std:account:list": "1ad8433c-d405-4227-9896-dbed5d1e6bc4"
}

I hope this helps identify the issue.

11

Thanks @moises_proof thatā€™s interesting. Any chance you could share the syntax of the Context URL you used with the variable, as Iā€™ve tried everything I can think of.

From what I know the deltaAggregation connector settings are something to do with the state thatā€™s used in the SaaS Connectivity framework (see Account List | SailPoint Developer Community).

12

Sure @j_place , below are the details for both connectors.

For the VA-based connector, the configuration is:

/accounts?since=$application.lastAggregationDate_account$

And here is the log from my application showing the delta request it received:

[2026-02-23T17:35:56Z] [adapter_app] [INFO] šŸŸ¢ 200 GET /accounts?since=2026-02-19T12:27:09Z

For the SaaS version, I am using the same URL:

/accounts?since=$application.lastAggregationDate_account$

And this is the corresponding log captured in my application:

INFO:     3.228.248.125:0 - "GET /accounts?since=2026-02-23T17:36:34Z HTTP/1.1" 200 OK

And just to clarify, at no point did I modify the SaaS connectorā€™s JSON configuration. I did not manually create an attribute named lastAggregationDate_account inside connectorAttributes.

If this was added on your side, I would suggest removing it, as it may be causing a conflict.