Skip to main content

Filter by idea status

10000+ Ideas

Let's Talk about Lists -- I would love a List Import Queue (wireframe included)New

We ran into issues with list imports the other day that was due to a cluster issue in the sydney datacenter where our instance is hosted. We had 4 lists that were "being imported" and never finished even after 4 days. This got me thinking, we have a Campaign Queue, why not have a List Import Queue/History... This could get cumbersome with how some of us use lists (campaign Triggering) but if it is either tabbed or categorized, based on the following it should be easy to filter and troubleshoot:Possible List Actions:List ImportAPI List ImportFlow: AdditionFlow: RemovalHere is a quick and rough mockup -- forgive any inconsistencies, I'm writing in stream of consciousness.StatusActionList Name(With List ID and Link)Program/Location Name (With Program/Location ID and Link)Start Day Date & TimeEnd Date & TimeView list of...In ProcessList ImportLI 10 -- Import to Program(LI124488)EVSP 2017-07 -- My Sponsored Event -- MKTO-SFDC (PG2430)7/11/2017 10:00:007/11/2017 10:03:00Leads ProcessedQueuedAPI List ImportLI 10 -- Import to Program (LI12498)PROB 2017-07 -- My Promotional Outbound Lead Gen Program -- MKTO-SFDC (PG2410)7/10/2017 14:00:007/10/2017 14:05:00Leads ProcessedCompleteFlow: RemovalLI -- My Global Static List (LI1244)Lead Database (ML0)7/9/2017 15:05:007/9/2017 15:05:32Leads ProcessedCompleted With ErrorList ImportLI 10 -- Import to Program (LI124401)EGEB 2017 -- My Ebook Program -- MKTO-SFDC (PG2435)7/8/2017 08:00:007/8/2017 08:00:00Leads ProcessedLeads with ErrorsIn Process / StuckImport to ListLI 10 -- Import to Program (LI124307)EMOP 2017-07 -- Operational Email -- MKTO-SFDC (EBP435)7/7/2017 10:00:00AMLeads Processed to DateCompleteFlow: AdditionLI -- Static List (LI1244)Lead Database (ML0)7/6/2017 15:00:007/6/2017 15:01:32Leads ProcessedLastly, this type of view could be helpful for any asset, program, smartlist etc. Could be more widely applied.If this is already on your docket as part of an upcoming release mentioned at summit -- my bad, but I hope it helps Cheers,David

FrederikWerner
FrederikWernerNew Participant

Make default Component Names more readable in Customer Journey AnalyticsNew

Description - Today, default Component Names in Customer Journey Analytics are based on the XDM display name of the field alone. However, that leads to potentially many components having the same name (1) while coming from very different paths in the Schema (2): This makes it hard to understand which, in this example, Type a component really is. To help this, CJA admins have to chose between two bad options: Leave the XDM Schema unchanged (using descriptive display names which only describe the current node) but having to manually change the component name in every connected Data View Changing the XDM Schema display name for all fields to include more information than actually required to avoid having to change many fields in CJA To help with this issue in CJA while keeping the XDM Schema clean, I propose to make the duplicate check smarter. Today, a number is added to the name to make the name unique. Ideally, in case of a duplicate component name, the display name of the field in question would be prefixed with the display name of the parent node, like the parent shown below: In this example, instead of showing up as "Type (3)", the component would be named "Web interaction Type" (field's display name prefixed with display name of parent node), possibly with a delimiter, like "Web interaction > Type". If that is not enough, more parent nodes could be added until the name is unique or the full tree has been traversed, in which case numbers could be used as a last resort. This small change would help users of CJA understand the context of a component, while making admin's lives easier.