Build better products with our product team
Problem Statement :How can we support near real-time or frequent audience evaluation in AEP, when the platform only allows one scheduled batch segmentation run per day and does not support sub-daily automation? Solution: In Adobe Experience Platform (AEP), batch segmentation is designed for daily execution (one run per day per sandbox). This becomes a challenge when business requires more frequent audience refresh (hourly or near real-time use cases).To handle this, AEP provides a combination of on-demand execution, optimization strategies, and alternative approaches. 1. Understand the Core LimitationOnly 1 automated batch run per day per sandbox No hourly or multiple recurring schedules supported Schedule timing (default 5:00 AM UTC) can be modified only via API, not UI👉 This means native batch segmentation cannot meet high-frequency use cases 2. Use Flexible Audience Evaluation (FAE) – On-Demand RunsTo overcome this limitation, AEP provides Flexible Audience Evaluation (FAE).✅ What FAE does:Triggers immediate batch evaluation Bypasses waiting for the daily scheduled run✅ But comes with strict limits: 3. Optimize FAE Usage (Important Strategy)Since FAE is limited, we must use it efficiently:Bundle up to 20 audiences in one FAE job Avoid running segments individually Reserve FAE for: Critical campaigns Urgent business needs Ad-hoc activations 👉 Not suitable for continuous/hourly automation 4. Best Practice: Move to Streaming Segmentation (Recommended)For near real-time use cases, the correct approach is:✅ Use Streaming SegmentationEvaluates users as data arrives Supports near real-time audience qualification No dependency on batch schedules✅ When to use:Frequent updates (hourly / multiple times daily) Real-time personalization use cases Event-driven targeting 5. Important ConsiderationsStreaming audiences must be enabled properly If audience is required in downstream systems (like CJA), ensure batch evaluation is also enabled (if needed) Final RecommendationUse Batch Segmentation → For daily use cases Use FAE → For limited on-demand runs (critical only) Use Streaming Segmentation → For real-time or frequent updates
Hi Everyone,I wanted to share a new Chrome extension I’ve been using called TagScanner that has significantly streamlined my Adobe Tags (Launch) auditing workflow.As implementation scale increases, keeping track of library bloat and rule dependencies can get tricky. TagScanner helps by loading all details about any Adobe Tags property directly from the page.Key Features:Direct Page Reading: It reads the Tags library directly from the browser—no remote code or extra permissions required. Comprehensive Visibility: Quickly view all active Rules, Data Elements, and Extensions in a single interface. Performance Insights: It displays exact file sizes and usage details, making it much easier to identify "heavy" rules or unused code that might be slowing down your site. Effortless Documentation: Perfect for cleaning up legacy properties or creating implementation documentation for stakeholders.It’s been a great addition to my toolkit for quick audits without having to dig through the Data Collection UI every time.Has anyone else tried it yet? I’d love to hear how you’re currently handling your implementation clean-ups or if you have any other "must-have" extension recommendations! Please find extension- https://chromewebstore.google.com/detail/tagscanner/mhejdbndckkddicchjjbaehfbmjjlmjn?utm_source=item-share-cb Thanks,Santosh Kumar
Workfront Fusion does not account for Daylight Savings Time, which is confusing when mangaging Scenarios and evaluating Cycles/Executions, especially because Workfront does account for DST.
The Monday morning that never ends Picture this: it's Monday, and Priya, a journey orchestration lead at a retail brand, has three journeys on her plate. A loyalty re-engagement flow. A trial-to-paid conversion path. A seasonal promotion for a new product line.Each journey needs the same opening move: read the audience, run an eligibility filter, and drop anyone who doesn't qualify. Priya has built that logic at least a dozen times. She knows it by heart. She also knows that if she copies it from an old journey, she'll spend the next hour untangling node references, fixing namespace mismatches, and wondering whether this version matches the one her colleague Marcus built last month.By Tuesday, she's still wiring up the same three nodes. Again.This is the quiet tax of journey building — not the creative work of designing a great customer experience, but the repetitive work of rebuilding logic your team already trusts. Journey Fragments exist to eliminate that tax. What if your best journey logic lived in one place? Journey Fragments live in a shared inventory and drop into any journey as reusable logic blocks. Journey Fragments are reusable blocks of journey logic — a connected set of nodes you build once and drop into any journey across your sandbox. Think of them less like a template document and more like a proven recipe your whole team can cook from.An eligibility check. A preferred-channel router. A three-step welcome sequence. A "did they open the email?" reaction loop with a reminder. These aren't one-off canvas experiments anymore. They're assets — authored, versioned, and stored in a dedicated Fragment Inventory under Journeys → Fragments.When Priya finishes her eligibility logic in a test journey, she selects the nodes on the canvas, clicks Save as Fragment, gives it a name, and moves on. Next time Marcus needs the same pattern, he drags the Journey fragments activity from the left rail, picks Standard Eligibility Check from the picker, and drops it in. Done.No copy-paste archaeology. No "which journey had the good version?" Slack threads. Two paths in, one library out Two ways to create a fragment — both land in the same shared library. There's no single "right" way to create a fragment — and that's intentional.From the canvas (the path most teams love): Build and test your logic inside a real journey first. Run simulation. Make sure the nodes behave the way you expect. Then select them and save. This is the recommended path when accuracy matters — because the fragment editor itself doesn't offer test mode or simulation. You're authoring logic, not guessing at it.From the Fragment Inventory: Start fresh when you already know exactly what you're building — a simple channel router, a timed wait sequence, something you've validated mentally and want to formalize. Click Create journey fragment, build on the fragment canvas, save as draft, activate when ready.Either way, the output is the same: a named, reusable piece of journey logic sitting in your team's shared library. From draft to deployed — the lifecycle that keeps things sane Fragments aren't wild-west copy-paste. They follow a clear lifecycle:Draft — work in progress, editable, not yet available in the picker Active — validated and ready to insert into journeys Archived — retired from use, but preserved for referenceOnly draft fragments can be edited or deleted. To change an active one, deactivate it first. When you're ready to share it with the team, activate it — most of the same validation checks that run during journey publication apply here too.One thing worth knowing upfront: contextual attributes and governance policies aren't fully evaluated at activation time. Those checks happen when the fragment is actually inserted into a journey and runs in context. That's by design — a fragment is portable logic; the journey is where it meets your specific audience and rules. Drop it in. Move on. Inserting a fragment creates a static copy — your live journeys stay stable. Using a fragment is deliberately simple:Open your journey Drag Journey fragments from the activity rail Drop it onto a branch — or onto an empty canvas if the fragment starts with a Read Audience, Audience Qualification, or Event node Browse or search the picker, preview if you want, select, and insertThe nodes appear on your canvas at the drop point, fully configured, ready to connect to the rest of your journey.Here's the part that surprises some teams the first time: inserting a fragment creates a static copy. If Priya updates the original "Standard Eligibility Check" fragment next quarter, journeys that already used it won't automatically change. That's a feature, not a bug — it means existing live journeys stay stable while your library evolves. When you want the new version, you insert it fresh.Four patterns teams are already reusing The best fragments aren't exotic. They're the logic your team builds over and over:Eligibility checks — Read Audience plus your standard filters. Same entry criteria, every journey, every time.Preferred channel routing — Email, push, or SMS based on profile preference. One fragment, every outbound journey.Onboarding welcome sequences — Three timed messages introducing a product. Swap the audience, keep the sequence.Reaction-based reminders — Send an email, wait for an open, nudge if nothing happens. The nurturing pattern that used to take an afternoon now takes a drag-and-drop.These aren't abstract examples. They're the patterns that turn a two-day journey build into a two-hour one. A few guardrails worth knowing (without the manual feel) Every good reusable system has boundaries. Journey Fragments keep things manageable:One entry path per fragment — no multi-fork selections Up to 20 nodes per fragment No Jump activities inside fragments Only connected nodes can be saved together Up to 200 active fragments per sandbox Journeys on the old stack (inline campaigns) need to be duplicated to the current stack firstThese limits aren't there to frustrate you. They keep fragments focused — small enough to understand, large enough to be genuinely useful.And if you're wondering: Journey Fragments are not content fragments. Content fragments are reusable email components — headers, footers, blocks. Journey Fragments are reusable logic. Different problem, different tool. AEM Content Fragments are a third thing entirely — content authored in Experience Manager, not journey orchestration. What this means for your team Back to Priya. By Wednesday — not Tuesday — she's shipped all three journeys. The eligibility check came from the fragment library. Marcus's preferred-channel router dropped in without a meeting. The welcome sequence was the same one the onboarding team activated last month.What changed wasn't her skill. It was the infrastructure around her work.Journey Fragments don't replace the craft of journey design. They protect it — by removing the repetitive rebuilds that eat your week and introduce inconsistency across your sandbox. Build once. Reuse everywhere. Spend your time on the journey, not on the plumbing.Real-world example: Post-purchase loyalty journey Caption: Three teams, three fragments, one journey assembled in minutes. Here’s how a retail brand might use Journey Fragments to build a post-purchase loyalty journey:Step What happens Fragment Owner Trigger Order Confirmed (Event) — — 1 Active loyalty member? Eligible for upgrade? Eligibility Check Finance team 2 Branch by tier: Gold / Silver / Bronze actions Tier-Based Routing Loyalty team 3 Wait 3 days → NPS email → Wait 7 days Post-Journey Survey CX team Each fragment was created and owned by a different team. The journey author assembled them in under 30 minutes — with confidence that the logic was production-tested and team-approved.
Modern customer journeys rarely stay inside one system. They depend on loyalty platforms, billing engines, CRM tools, fulfilment services, and partner APIs. When one of those integrations fails, the reason behind the failure matters just as much as the failure itself.A temporary outage may need a retry. A duplicate request may need no action at all. A suspended account may require customer service intervention. But until now, custom actions in Adobe Journey Optimizer could detect that a call failed without giving journeys access to the structured error details many APIs already returned.AJO 26.1 changes that with Error Response Payload Support for custom actions. What's New: Error Response Payload Support Custom actions have long supported success response mapping. When an API call succeeds, you can define the response structure, parse the body, and use those fields later in the journey.Previously, error handling worked differently. If a custom action returned a 4xx or 5xx response, AJO recorded the failure status, but it did not surface the response body even when the endpoint returned useful error details.That created a hard limit for journey design. A journey could tell that something went wrong, but not why.With Error Response Payload Support, that changes. You can now define an error response structure for non-2xx responses, and AJO will capture those fields in the journey context under the errorPayload namespace.To be clear, AJO does not invent or infer error details. It simply captures what the REST endpoint itself returns in the error response body. If your API already returns structured error information, you can now use it in the journey in the same way you use success response fields today.Both success and error response fields are available in the journey context, giving you flexibility to use them across normal, error, and timeout paths. A Practical Example Consider a loyalty reward campaign. A journey identifies an eligible subscriber through an audience node and then calls a loyalty platform API to credit reward points. Now imagine that the API returns a failure response like this:{ "errorCode": "ACCOUNT_FROZEN", "errorMessage": "Account is temporarily suspended", "retryEligible": false} That means the next condition node can make a meaningful decision:errorPayload.errorCode == "ACCOUNT_FROZEN" → route to a customer service notification path errorPayload.errorCode == "ALREADY_CREDITED" → end the journey silently for a duplicate request errorPayload.errorCode == "PLATFORM_UNAVAILABLE" → wait and retry laterThe journey is no longer reacting to failure in the abstract. It is responding to the actual reason the API gave. What This Unlocks This feature does more than improve technical observability. It improves journey quality, operational efficiency, and customer experience.It helps teams react to the specific error, not just the fact that something failed. A validation issue, a duplicate request, and a service outage can now lead to different business outcomes instead of the same generic fallback path.It helps teams design journeys around the full API contract, not just the happy path. Error responses are part of how modern APIs communicate state. AJO now lets you map and act on both success and failure responses, so integrations become more complete and more predictable.It also helps teams build journeys that degrade more gracefully. When an integration fails, the customer experience should not collapse into a dead end. With structured error context, you can design better fallback paths — a retry, an alternative channel, or an internal escalation — based on the exact failure. Getting Started Setting this up takes a few minutes in the custom action configuration:Go to Administration > Configurations > Actions and try to create a custom action In the Response tab, you'll now see two sections: Success Response and Error Response Define your error response schema to match what your endpoint returns for non-2xx responses Publish a new journey version — the feature is ready to be used in your condition node.
We would like to see some enhancements to milestone paths. Currently you can only associate one milestone path to a project. This creates limitations on enterprise-wide reporting. If we want a global milestone path associated to all projects, then agencies cannot apply a local milestone path to manage work. If leadership wants to see all projects across the enterprise for planning (revenue etc.) We currently have no mechanism to do that.
Planning has all these great ways to customize views, but no way to capture those views to showcase in reports. For example, you can create a great timeline view and customize what is visible, but you have to use a screenshot tool to get that image in the hands of stakeholders. One tool that does this really well is Lucid. When you go to expert a chart, it gives you the option right there to crop it and choose exactly what to include. Even with tables, it would be helpful to capture the view for use in a PowerPoint without using copy and paste and having things go wonky on the paste part.
This is a request to have the Emergency pipeline execution mode, currently available for AEM on-pem (Code Deployment | Adobe Experience Manager), added to AEM as a Cloud Service.
Right now, we can only export meta data on a folder level. This is impractical if you need to edit only meta data for 30 assets, but then wait hours for a folder meta data report because there are 5k assets in a folder. And no, smaller folder is not an option here. So what would be preferrable is that you simply select any assets you want and click “export metadata”. The upload of meta data should support this, so that you can add the meta data e.g. for the top folder and it will be applied to all assets in the csv, regardless of their sub folder location (not tested in current environment - maybe this works already?).
Have you ever noticed a strange behavior in Adobe Experience Platform (AEP)? You can build a structural blueprint called a Schema with a special map called an identityMap. You can add an email and a phone number as normal identities, but leave the "Primary Identity" field completely blank. The system still allows you to click "Enable for Profile" and save it without any errors at all!It looks like everything is working perfectly. But underneath the hood of Real-Time CDP, this creates a hidden trap: the system will connect your IDs in the map, but it will fail to create actual customer profiles.Let’s understand why this happens using a simple story based on a real-world company: Walmart. The Problem: Missing Profiles Imagine Walmart is tracking digital shopping activity using an AEP Schema. A customer goes online and makes a purchase, providing their phone number and email.Because the Walmart Schema has an identityMap at its root, AEP stores this transaction. Later, a data analyst checks what happened inside the system: The Identity Graph (Success): The system sees the phone number and the email and links them together. It knows both belong to the same customer. The Real-Time Customer Profile (Failure): The marketing team tries to find the customer’s profile to check purchase history or preferences, but no profile exists. The system connected the dots, but it failed to create the actual profile.All the valuable data ends up stored as raw records in the Data Lake, instead of being organized into actionable profiles. The Architecture: Two Different Workers Why does this happen? Because AEP has two independent systems working behind the scenes: Worker 1: The Graph Builder (Identity Service) This system focuses only on linking identities. If the same phone number appears in multiple places, it links them together. It does not create profiles. This is why the identity graph looks correct. Worker 2: The Profile Builder (Profile Service) This system is responsible for creating customer profiles. To build a profile, it requires one main identifier (Primary Identity). When you save the schema without defining a Primary Identity, you are relying on the incoming data to specify it later.If the incoming data does not clearly define which identity is primary, the Profile Service cannot proceed and does not create the profile. The Solution: Fixing the Data Payload Since the responsibility shifts from schema design to the data payload, the fix must be applied in the data being sent.Every data payload must explicitly define the primary identity using "primary": true.Correct JSON Example{ "email": "shopper@walmart.com", "phone": "+1234567890", "identityMap": { "Phone": [ { "id": "+1234567890", "primary": true } ], "Email": [ { "id": "shopper@walmart.com", "primary": false } ] }} ✅ Why This WorksThe Identity Service links both identities. The Profile Service identifies the primary identity using "primary": true and creates the customer profile.🔑 Key TakeawaysAn identityMap without Primary Identity shifts responsibility to the data payload. Identity linking is not equal to profile creation. Always ensure one identity is marked as "primary": true in every payload. Without this, data remains isolated in the Data Lake and does not form unified profiles in RTCDP.
Simulation Mode lets you test draft journeys using Simulated Users — AJO-native temporary profiles that are fast to create, reusable across journeys, and completely separate from AEP test profiles. If you have read the getting-started guide, you have seen how Simulation Mode works for a single journey with a branching condition. This post goes one level deeper: two journeys running in sequence, sharing a single simulated user, where Journey 2 writes profile attributes that Journey 1's condition reads.The use case is credit decisioning. Journey 2 fires on a credit decision event and writes the outcome and the decline reason to the simulated user's profile using an Update Profile node. Journey 1 fires on a product campaign trigger, waits 2 hours, then reads those profile attributes to route the customer to an approved onboarding email or a personalised declined email that renders the specific reason inline.The goal is to prove — with green lines in the Results tab — that the correct email goes to the correct customer profile, and that the decline reason renders correctly in the email body, before either journey goes live. WHAT SIMULATED USERS BRING TO CROSS-JOURNEY TESTING Before walking through the setup, it is worth understanding what makes Simulated Users the right tool for this specific problem.In a single-journey simulation, a Simulated User enters the journey, traverses the nodes, and you read the Results tab. The user's profile attributes are either pre-set when you create them, or written during the run by an Update Profile node.That second behaviour is what enables cross-journey testing. When Journey 2's Update Profile node executes during a simulation run, it writes to the Simulated User's profile — the same profile that Journey 1 will read when you run Journey 1's simulation for the same user. The two journeys share profile state through the Simulated User, exactly as they would share profile state through a real AEP profile in production.This means you can test the full chain:Create one Simulated User with blank credit decision attributes. Run Journey 2's simulation for that user — the Update Profile node writes creditDecision and declineReason to their profile. Run Journey 1's simulation for the same user — the condition node reads those attributes and routes to the correct email branch. Read the Results tab in Journey 1 and confirm the path and the personalised content.You are not mocking or pre-seating the result. You are running the actual write-then-read chain that production will execute, using the same journey canvas, the same Update Profile node, and the same condition expression — with a Simulated User standing in for the real customer. THE JOURNEY ARCHITECTURE Journey 2 — Credit DecisioningTrigger: Credit decisioning event (fired by your underwriting system or decisioning API when an application is reviewed).Nodes: Update Profile — writes three fields in a single activity.Profile field Value source Field type creditDecision @event{creditDecisioningEvent.decision} String declineReason @event{creditDecisioningEvent.declineReason} String decisionTimestamp @event{creditDecisioningEvent.timestamp} String End.creditDecision carries "approved" or "declined". declineReason carries a human-readable explanation — "debt-to-income ratio", "insufficient credit history", "identity verification required" — populated when declined, null when approved. All three are simple string fields, fully supported by the Update Profile node without any workarounds.Journey 1 — Product Campaign Trigger: Product campaign trigger event (a campaign broadcast, a segment qualification, or a product page visit — separate from the decisioning event).Nodes: Wait (2 hours) → Condition → Email action (approved path) / Email action (declined path).Condition expression (simple expression editor):profile.creditDecision == "approved"Approved path: onboarding email with credit limit and next steps. Declined path: alternative product email with {{profile.declineReason}} rendered inline. Fallback path (other cases): holds profiles where creditDecision is null — not yet decided, or Journey 2 has not yet run. Neither email fires.STEP 1: CREATE THE SIMULATED USERSYou need three Simulated Users — one for each meaningful state the system needs to handle.Open any journey (Journey 1 or Journey 2), click Simulate, and choose Simulation. Click Create Simulated Users.User A — Approved applicantField Value Display name T1 – Credit Approved Email A real inbox you have access to creditDecision Leave blank declineReason Leave blank User B — Declined applicant (debt-to-income reason)Field Value Display name T1 – Credit Declined DTI Email A real inbox you have access to creditDecision Leave blank declineReason Leave blank User C — No decision recordedField Value Display name T1 – No Decision Recorded Email A real inbox you have access to creditDecision Leave blank declineReason Leave blank Leave creditDecision and declineReason blank on all three. Journey 2 will write these for Users A and B. User C never enters Journey 2 — their attributes stay blank throughout, which is exactly the null-state scenario you need to verify.Click Save after creating each user. Saved Simulated Users are available across both journeys via Select Simulated Users — you create them once and reuse them for the entire test sequence. STEP 2: RUN JOURNEY 2 FOR USER A (APPROVED)Open Journey 2. Click Simulate → Simulation. Click Select Simulated Users and pick User A.Click Configure events to set the credit decisioning event payload for User A: json{"decision": "approved","declineReason": "Not Applicable","timestamp": "2026-06-18T09:00:00Z"}Click Send. The journey canvas activates. Watch the path trace on the canvas — the green line should move through the Update Profile node and reach End.Open the Results tab. Select User A from the dropdown. Open the Update Profile node detail and confirm both writes executed:creditDecision written as "approved" declineReason written as "Not Applicable"This is the state Journey 1 will read when User A reaches the condition node. You can also check if the data is updated in the simulated user profile by viewing the simulated user. STEP 3: RUN JOURNEY 2 FOR USER B (DECLINED)Still in Journey 2 Simulation Mode, click Select Simulated Users and switch to User B. Configure the event payload: json{"decision": "declined","declineReason": "debt-to-income ratio","timestamp": "2026-06-18T09:05:00Z"}Click Send. Confirm in the Results tab that the Update Profile node executed for User B and both fields are written:creditDecision written as "declined" declineReason written as "debt-to-income ratio"Do not run Journey 2 for User C. Leave their profile attributes blank. The null state is part of what Journey 1 needs to handle correctly.Close Simulation Mode on Journey 2. Journey 2 returns to Draft status. The writes to User A and User B's profiles persist — those attributes are now readable by Journey 1. You can also check if the data is updated in the simulated user profile by viewing the simulated user.STEP 4: RUN JOURNEY 1 FOR ALL THREE USERSOpen Journey 1. Click Simulate → Simulation. Open Test Settings and compress the Wait node duration to a value that lets you complete the simulation quickly — 30 seconds is enough. The 2-hour wait is the production window for profile propagation; in simulation, the attributes are already written so you just need the wait node to clear.Click Select Simulated Users and pick all three: User A, User B, and User C.Click Configure events and set the product campaign trigger event. This event is the same for all three users — it is the entry event into Journey 1, not related to the credit decision. Send for all three simultaneously using Send all.All three users are now parked at the Wait node. After the compressed wait elapses, the condition node evaluates for each user. STEP 5: READ THE RESULTS TABOpen the Results tab. Use the dropdown to switch between users.User A — expected: approved pathSelect User A. The green line should branch to the approved email node. Open the condition node detail and verify:profile.creditDecision read as "approved" Condition evaluated true on the approved pathOpen the approved email action node detail and confirm the approved email template was selected. Verify declineReason does not appear anywhere in the approved email's rendered output — it should not be present because the approved email template does not reference that attribute.User B — expected: declined path with reason renderedSelect User B. The green line should branch to the declined email node. Open the condition node detail and verify:profile.creditDecision read as "declined" Condition evaluated false on the approved path, true on the declined pathOpen the declined email action node detail and confirm:The declined email template was selected {{profile.declineReason}} rendered as "debt-to-income ratio" in the email body The conditional content block specific to DTI decline ({%#if profile.declineReason = "debt-to-income ratio"%}) selected the DTI-specific alternative product sectionUser C — expected: fallback path, no emailSelect User C. The green line should route to the fallback path — neither the approved nor the declined email. Open the condition node detail and verify:profile.creditDecision read as null Both conditions evaluated false Fallback path triggeredIf User C routes to either email instead of the fallback, the "other cases" path is not configured on the condition node. Add it before publishing — this path handles profiles where no decision has been recorded, and sending either email to those profiles is incorrect.Select AllSwitch the dropdown to All Users. Dark grey lines on the canvas show the collective path coverage. You should see two lines diverging at the condition node — one to each email branch — and one line reaching the fallback. This single view confirms all three paths were exercised in this simulation run.STEP 6: CLOSE SIMULATION MODEOn Journey 1, close Simulation Mode from the same Simulate menu where you opened it. The journey returns to Draft status.User A, User B, and User C remain saved in your Simulated Users library. The next time you update either journey — a new reason code in the event schema, a change to the condition expression, a revised email template — you reopen Simulation Mode on each journey, select the same three users, and rerun the same sequence. The full test takes under ten minutes once the users are built.WHAT THIS SIMULATION RUN PROVESRunning all three users through both journeys in Simulation Mode gives you confirmed evidence of five specific behaviours before either journey goes live:The Update Profile node in Journey 2 correctly writes both creditDecision and declineReason from the incoming event payload to the Simulated User's profile. The condition node in Journey 1 correctly reads creditDecision and routes approved profiles to the approved email and declined profiles to the declined email. {{profile.declineReason}} renders the correct reason string in the declined email body. Conditional content blocks in the declined email select the correct alternative product section by reason code. Profiles with no credit decision recorded (creditDecision = null) route to the fallback path and receive no email.Each of these is shown as a green line on the canvas and confirmed in the node-level detail view. That is the audit trail — screenshot it and keep it with your launch documentation. REFERENCESSimulate your journey — AJO Documentation Update Profile activity — AJO Documentation Getting Started: Simulation Mode from Zero to First Run (ExL Community)
m
Using Ai search, we would like to have search operators enabled to be able to search for exact terms. The search operators “ “ as known from Google etc. would be the highest priority, enabling us to search for an exact combination of search keywords.
We sometimes have up to 20 documents in one project that need approval. I would like to be able to select them all and send one approval (but still have an approval on each document)
Some of our reports need to be filtered to only show data from members who belong to a certain Team. Only Home Team is available as a filter in reporting, so, in order for a person's data to display on a report, we have to make sure we remember to make their Home Team match the filter on the Report. This works OK, but it means that if a person belongs to more than 1 team, they can only show up on 1 report that is filtered by Home Team. If we could select Other Teams as a filter on a report, then we wouldn't have to remember to make the report filter match their home team, and we could also have the person appear on all of the reports that are filtered by Team.
Description - Would like to be able to display percentages on bar chart reportsWhy is this feature important to you - Leaders would like to be able to see percentages on reports and teams are having to exports reports and recreate charts in Excel. This creates additional work and data comes stale as soon as we export to create these manual reports.How would you like the feature to work - Add an option to allow us to toggle on percentages for bar charts.Current Behavior: This does not exist. Duplicate idea
Please add the ability to delete multiple items at once within Marketo Engage.
There used to be an interface within Marketo that allowed the deactivation of multiple trigger campaigns at once. This was a great time saver and would be very useful to reimplement. It is painful and severely time-consuming to have to manually go to each folder within each program to deactivate trigger campaigns.
Please update UI so that when smart campaigns (and possible other items) are deleted, the UI doesn't scroll to the top of the instance. This is highly irritating and wastes time for end users who have to scroll back down to the folder they were working in.
Description - Currently if a user sorts the task list by something other than task number, the tools for indenting/outdenting and adding tasks above/below the line become inaccessible. Instead of making them inaccessible, show those tools and pop up error messages telling the user the task list needs to be sorted by task number to use this feature and give them a button to immediately resort their task list by task number to proceed. Why is this feature important to you - Users are constantly sorting their list by another column, not realizing this, and then getting extremely frustrated when they cannot find the indent/outdent and add task above/below tools. I have users run into this issue pretty consistently. How would you like the feature to work - It would be a more user friendly approach to instead show the user the tools and tell them that they can't use them without re-sorting their task list by task number. It would be even better if you could also give them the option to do that re-sort in the error pop up so they can proceed. Current Behaviour - The tools for indent/outdent and adding task above/below just disappear and cannot be found. They do not indicate why they disappeared or what step needs to be taken to fix the issue.
Users need the ability to do fuzzy lookups in Marketo Design Studio so that we don’t waste time and resources within the platform recreating and uploading duplicate images and files. This feature was removed a while back without consulting users on whether they needed the ability to do this.
One of the few concerns I have had with Workfront is that, for larger projects, there is nothing that I see that relates to a project charter that should be created in the Initation process group or the project management plans that are major parts of the Planning process group. The intake and custom form has been helpful for projects that require less detail or planning, but not for the major initiatives. For those projects I try to keep to PMI (Project Management Institute) standards. Are you able to develop or account for those needs within Workfront? Also, if you don't have a PMP professional or PMI professional consultant, I would recommend that you have one be heavily involved/ consulted in Workfront development.
We are currently unable to capture url parameters when a user engages with a dialogue in Dynamic Chat. This is a big miss IMHO because it means we're unable to align dynamic chat engagement with campaign activities, or campaign costs. Many people user UTM parameters, and we currently use GCLID and CMPID as parameters to align user engagement to marketing activity, and marketing investment. Capturing these parameters is critical to showing DC value.
Marketo Dynamic Chat currently does not appear to support capturing UTM parameter values and updating them in Marketo fields. Having this capability would be valuable for campaign attribution, lead tracking, and downstream automation. We would appreciate Adobe considering this enhancement in a future release.
We need the ability when we set up automated scheduling of reports to have an expiration date of “NEVER”. Its very inconvenient to have reports from either analytics or the new adobe report builder to aways hit an expiration date that has to be kept up with.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
