Skip to main content

Filter by idea status

10000+ Ideas

Feature request: The new Update Variable action in the AEP Web SDK Launch extension would be a lot more helpful if you could start with an existing XDM data element and update thatNew

The new Update Variable action in the AEP Web SDK extension would be a lot more helpful if you could start with an existing XDM data element and update that, rather than having to start with an empty XDM object every time.In the scenario where you’ve got a lot of fields that you want to set on every event (e.g. domain, customer id, whatever), I’d want to start with an XDM object that’s already got all those fields populated, and then update that. Likewise, if I've got a lot of ecommerce events, I would want to start with an XDM object where the basic productListItems array is already defined, and then just update that with the relevant additional fields for the particular event (product view, basket add, etc)Currently, you have to start with an empty object in every rule, so you end up repeating a lot of work if you have rules that share a lot of fields.Another, perhaps better, option would be if you could just do the equivalent of the Merge Objects data element in rules. For example, if I've got some default 'global' fields that I want to set in every event, and I've got some standard ecommerce fields that are set on all ecommerce events, a simpler workflow would be:Create an XDM data element that contains all my global dimensions.Create an XDM data element that contains all my standard ecommerce fields.In my 'cart add' rule:Start with the 'global' XDM data elementMerge it with the 'ecommerce' data elementUpdate it with a few fields that are specific to the cart add (e.g. carts adds metric)Then I could just duplicate this rule for all my ecommerce events, and just tweak the final 'update' action depending on if its a product view, cart remove, etc. This would be much cleaner than the current situation where you eitherHave one XDM data element per rule, where you're repeatedly setting the same 'global' and 'ecommerce' XDM fields.Have layers of 'merge object' data elements, where you build up the object before putting it in the rule (e.g. global + ecommerce + cart add)Use the Update Variable action where, again, you're repeatedly setting the same XDM fields over different rules.

cvergesLevel 5

Allow for running other Fusion scenarios within the same scenario processNew

From time to time, we have one Fusion scenario call another Fusion scenario in order to centralize things like authentication token management.  (An example of this is when we call NetSuite, where NetSuite requires a specialized token process that isn't supported out of the box by Fusion's credentials mechanism.)  Adobe PS recommended we put the token generation/retrieval process be put in its own scenario, and then call that scenario in whichever scenarios we'll be doing further business logic (such as calling NetSuite for some specific API calls using that token gathered before).The issue we're finding is that Fusion sometimes returns an "Accepted" response rather than the intended webhook JSON.  Basically, it looks like Fusion webhooks are not guaranteed to execute when called but may be queued under some loading conditions.  Retrying isn't necessarily guaranteed to fix this, either.What's really needed is the ability to execute that dependent/child scenario _within_ the runtime of the parent scenario.  That is, we should be able to avoid the "Accepted" error if we can directly execute a second Fusion scenario rather than having to call it via a webhook.So the ask is for some kind of Fusion module or other implementation to allow for temporarily suspending the current scenario, calling a specified scenario (and passing in appropriate parameters), having that second scenario return a response, and then start executing the original scenario using the response returned as a data point.

KierstenKollins
KierstenKollinsNew Participant

New Home: Create a New Home area in Setup for Global Group Updates for Widget SettingsNew

Description - Create a new space in the setup area for New Home updates that can be applied as global settings for groups Why is this feature important to you - Currently, having the ability to make changes on layout templates is awesome for widget settings, but it is a lot to manage and customize all the different templates we have. I am currently adding in the same the same custom fields, filters, groups and views for each template that we use so all the teams have access to the same settings. We have slight variances in our layout templates for our users, so I am not able to move to one universal layout template for all users to reduce the workload as an admin to manage settings.  How would you like the feature to work - Under the setup area, a new area would be made available to admins to be able to make updates to widget settings for groups globally. This would reduce the chances of human error if some layout templates are missing custom fields, filters, groups and views that are manually being turned on for multiple layout templates for different groups. Requesting for this to be global for the group level as we have 2 different businesses in our instances but some users cross over into both groups and would need access to both groups custom fields, filters, views and group. Current Behaviour - Currently only available to make setting updates under the layout template.