According to the connector documentation, the $getobject keyword should allow access to any account attribute. However, I’m facing an issue when using it in the contextURL of the getObject operation.
I’ve configured the operation and tried referencing an account attribute like $getobject.email$, but it doesn’t resolve correctly.
Has anyone successfully used $getobject in the contextURL of a getObject operation?
Is there a specific condition or limitation that prevents it from working in this context?
Any insights or examples would be greatly appreciated!
This is a common hurdle! You are correct that the documentation implies you can use $getobject.email$.
Why it may/might fail:
When ISC triggers getObject, it only passes the Native Identity (Account ID) to the operation. Therefore, other attributes like email are unavailable for substitution.
You can try using the WebServicesBeforeOperationRule instead.
Indeed, I implemented a beforeRule and I’m able to retrieve a single account using the email as the only parameter. However, the operation is triggered after the “Create Account” step. The account creation succeeds, but the action throws an error because the email is not recognized at that point.
You’re correct that only $getobject.nativeIdentity$ works reliably in contextURL for getObject operations. This isn’t a bug - it’s by design. During aggregation, when getObject operations typically run, the full account object isn’t populated yet, so most attributes beyond nativeIdentity aren’t available for URL construction.
The suggestion to use $plan.email$ works for provisioning operations but not for aggregation, which explains why it failed in your case. Plan variables are only available during provisioning workflows, not when you’re fetching account data during aggregation.
For your use case where you need to reference account attributes other than nativeIdentity during aggregation, you have a few options. First, if your target system supports it, construct your contextURL using the nativeIdentity and let the endpoint return the full account data including email. Second, consider using query parameters with the nativeIdentity to filter results on the target side. Some implementations use a two-step approach where the initial getObject call uses nativeIdentity, and subsequent operations use data from that response.
The fundamental limitation is that $getobject attribute access is context-sensitive and restricted during certain operations, particularly in URL construction during aggregation scenarios.
