I think I understand but one question unanswered is the following...If the following are correct entities should display in a recommendation?1. entity.id is being pass in the mbox and is the same entity.id found in the catalog2. Criteria is using "Current item" as the recommendation key3. Inclusion rules are verified to match 200+ entitiesOr even if the above are true do the entities matching the inclusion rules still have to have had an entity.id view (passed) in an mbox for the algorithms to d...

Any update on this? Been two years.

I saw in the Feb 12th release notes that you can now copy data elements, rules, and extensions to another Launch Property. This is a big win but copy an entire launch property and everything inside of it would be huge. We currently have 96 launch properties. We have to maintain library versions for 3+ extensions across all these. Making progress but looking forward to more.

I have this same frustration and created a separate idea for this exact user permissions just for mapping evars and props. But agree that the whole permissions for mobile need to be rethought.Enable users to map variables but not be an app admin

We had a similar issue. But the corrupt was the MCID and our Visitor ID were not being stitched since our visitor ID was not populating in our digital data layer when the MCID service ran. We use DTM for implementing our tools (analytics, target, and MCID). Our website is in angular so the data layer didn't populate before MCID service ran since it runs in an iframe on it's own without needing to wait for other analytics. Once we fixed that issue, our trigger event in ACS fired and the email was...

For companies like ours we have multiple websites (sub-brands) that have users who need same permissions but for their own report suite or virtual report suite. Basically need multiples of the same groups setup but each for their respective report suite. As we continnue adding report suites I have to manually add user groups. Copying/duplicating user groups is a big time saver for us. Promote, Promote, Promote!

This is a pain point for our organization as well. Having user permissions and groups at multiple levels: Enterprise, Analytics, Social, Target, Campaign and having to give someone access for social through Adobe Analytics doesn't make much sense. We have social media employees who post content, why do they need to be one of my users in Adobe Analytics, plus, someone with permissions to create users in Analytics has to be the one to give a new social person an account rather than a social media ...