Looking to use the API for the very simple reason - which I'm finding documentation difficult to come by and support is also chasing it's own tail - to ease the updating of segments that are nested in other segments. My belief was that they can be nested using the API, and then each time I update one of these nested segments, then each nested occurrence is updated as well, unlike in the UI whereby it is just a copy. Can someone please confirm or deny this possibility?
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
While I have never used the API for segment creation... my suspicion is that this use case is "sort of possible"...
By that, I mean I really can't see there being a way to "save" a segment inside a segment so that it auto updates... since the way that segments are saved doesn't seem to support a proper linkage (I don't see how using the API would allow them to save a different way to be honest)... however, assuming all segment updates being done by the API... I suppose you could create a logical mapping of segments inside of segments... so that:
IF Segment A is updated
I would assume it would be easier to keep the mapping as simple as possible... so that if there are Segments with B, D, F or H inside them would also indicate that they have A, so that you don't have to do recursive checks for segments containing B, D, F or H... but that might be needed... I mean, what happens if you make a change to B that removes Segment A and replaces it with an alternate... how do you break the "A" connectivity...
So you might be better doing nested to nested checks up the chain....
Either way, creating a way to document how the segments link together, and a process to update the portion of the segment that is nested is going to be tricky....
While I have never used the API for segment creation... my suspicion is that this use case is "sort of possible"...
By that, I mean I really can't see there being a way to "save" a segment inside a segment so that it auto updates... since the way that segments are saved doesn't seem to support a proper linkage (I don't see how using the API would allow them to save a different way to be honest)... however, assuming all segment updates being done by the API... I suppose you could create a logical mapping of segments inside of segments... so that:
IF Segment A is updated
I would assume it would be easier to keep the mapping as simple as possible... so that if there are Segments with B, D, F or H inside them would also indicate that they have A, so that you don't have to do recursive checks for segments containing B, D, F or H... but that might be needed... I mean, what happens if you make a change to B that removes Segment A and replaces it with an alternate... how do you break the "A" connectivity...
So you might be better doing nested to nested checks up the chain....
Either way, creating a way to document how the segments link together, and a process to update the portion of the segment that is nested is going to be tricky....
Thanks Jennifer. This was also my line of thinking. Probably a central source for each Segment's construct within our documentation (confluence) is the way to go, where I'd then copy/paste or reference the build using some kind of mapping.
I thought that a benefit of having Segment IDs, is that you could reference that ID within a nested container within a segment. And with hopeful enthusiasm thought it would be an "off-the-menu" item as I had read about it somewhere.... however it is has lended itself well as I had learned how to use the API via Postman.
I agree with you... nesting the Segment ID inside of another Segment would make sense... but if the Segment Builder doesn't store the information in this way, I don't see how you could force a segment to be saved with this dependency....
I know there have been many ideas / discussions about that sort of behaviour... basically, in my mind, when added a segment inside a segment, there should be a prompt to say "keep dependency" (where the ID should be stored as part of the definition, so that it uses the other segment, and updates as the segment is updated) or "make a copy" (where a copy of the definition is brought over as it is today without a dependency, allowing users to make changes).
The "dependent" segments should be non-editable (maybe with a link to the original for easier ways to make global changes)... and there should be a way to break the linkage later in case modifications need to be made without impacting the original or other linked segments.
And finally, when editing any segment that is linked inside of other segments, there should be a warning about what segments will be impacted by changes.
However, without Adobe providing this functionality (even in part), I don't think that you can make an ID linkage.... this would be a custom solution that would require a complex system of API calls to re-write all the "dependent" blocks of logic...
But this would likely be broken by any manual segment updates (unless you also run periodic checks for changes in segments not made via the API).
If you do get this working, I would love to see a blog on your solution!
Views
Replies
Total Likes
@uni-adam Did you find the suggestion helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!