Got a Web Services source with two Account Aggregation HTTP operations pulling different attributes from two different tables of the same external system, both correlated by the same identity attribute.
Main issue: when both operations run on the same source, only the attribute from one of them ends up on the account — the other one comes back empty, like it gets wiped out by the second operation instead of merging with the first.
Tried chaining them with Parent Endpoint thinking that would force a merge into one account, but it didn’t work.
Anyone dealt with this? Is there any way to actually get both attributes onto the same account, or is a separate Web Services source per table the only real solution here?
Welcome back, Antonio. Independent Account Aggregation endpoints do not join complementary attributes onto the same account. For that, operation 2 needs to be a child of operation 1 and use a value returned by the parent.
Make sure the join attribute is mapped in operation 1, set it as the parent, then use something like $response.<idAttr>$ in operation 2 and map only the additional attributes. SailPoint documents this pattern here: JSON aggregation.
If this is an older Web Services SaaS source, changing the Parent Endpoint setting may have no effect. Those sources use the previous chaining behavior where the first Account Aggregation operation is the parent and subsequent ones are children.
If table 2 is bulk-only and cannot be queried by that parent value, parent-child aggregation is not a good fit. For the VA-based Web Services connector, a Web Services After Operation Rule can enrich processedResponseObject using restClient, although paging and API volume need to be considered. If this is Web Services SaaS, use an after-operation Customizer instead of a connector rule.
A second source is another option, but it creates separate source accounts rather than merging both tables into one account.