Feed

@Jouni Hult my standard approach would be to use an Automated Email step when the email does not need personalization. A manual email step is designed for rep review/personalization, so using Flow to bulk-send it is possible, but it becomes custom automation and needs careful testing. 

For your "some need personalization, most do not" scenario, the best design is usually to split the audience before the email step. Put the non-personalized group into an automated email step, and keep only the recipients that need editing on the manual email step. That keeps Sales Engagement reporting, cadence progression, templates, limits, and engagement tracking much closer to standard behavior. Salesforce’s cadence data model has separate step types for AutoSendAnEmail and SendAnEmail, so this distinction matters (https://developer.salesforce.com/docs/sales/sales-engagement/guide/sales-cadence-objects.html) 

A Flow-based approach is technically possible, but I would treat it as a custom build, not a simple configuration. The Flow would need to identify the active ActionCadenceStepTracker records, retrieve the cadence step template, send the email, then call the standard Send Cadence Event action with ManualComplete. Salesforce’s Actions API includes sendSalesCadenceEvent for skipping or manually completing a step, and also includes selectTemplateForSalesCadenceStepTracker to retrieve the template/variant assigned to a cadence step (Actions Developer Guide) 

The main risk is that a custom Flow email may not behave exactly like a native Sales Engagement manual email. Before using this in production, validate email logging, opt-out handling, sender identity, daily limits, engagement tracking, reply/listener behavior, and whether cadence analytics still show the result correctly. 

So it would be like: use Automated Email for the no-personalization path, keep Manual Email only where reps truly need to edit, and use Flow only if the business accepts the custom behavior and testing effort.

To export Salesforce email sends/newsletter history to a file you can search through, here are the main approaches depending on where your newsletter emails are stored:

If you're sending through Salesforce standard Email (not Marketing Cloud): The EmailMessage object stores all sent emails. You can run a SOQL query or Salesforce report to export EmailMessage records including Subject, TextBody, HtmlBody, FromAddress, ToAddress, and MessageDate. From a Report, export to CSV or Excel, then you can search the content.

If you're sending through Marketing Cloud: Use the "Send Log" data extension or the Tracking Extracts feature to export send data and email content. You can access individual email renders through CloudPages or use the Email Tracking reports.

Quick options for search: (1) Salesforce Reports - create a report on Email Messages, export to Excel, and use Excel search. (2) Use the Salesforce Data Export (Setup > Data Export > Export Now) to export EmailMessage as a CSV. (3) If using Marketing Cloud, the Automation Studio tracking extracts can export HTML content.

Note: The body text of emails in Salesforce is stored in TextBody (plain text) and HtmlBody (HTML) fields on the EmailMessage object. A SOQL query like: SELECT Subject, TextBody, MessageDate FROM EmailMessage WHERE FromAddress = 'your@email.com' ORDER BY MessageDate DESC will get all your sent emails.

Mani G | Principal/Founder | https://Keneland.com

Best Architectural Approach for Multiple Inbound Interests

This is a classic Salesforce challenge, and you're right to be concerned about data integrity vs. sales UX. Here's the recommended architecture that balances all three goals:

Recommended Solution: Custom "Inbound Request" Object Pattern

Core Architecture

1. Single Lead/Contact Record (Identity Layer)

• Maintain one Lead or Contact record per person (your "identity" record)
• Use duplicate matching rules to prevent creation of duplicate Leads/Contacts
• Keep the original Lead Source and Status intact on this record

2. Custom "Inbound Request" Object (Interest Layer)

• Create a child object related to Lead/Contact: Inbound_Request__c
• Each web form submission creates a new Inbound Request record, not a new Lead
• This object captures:
  • Product/Service of interest
  • Campaign attribution (via Campaign Member)
  • Request date/time
  • Lead Source for this specific request
  • Status (New, Contacted, Qualified, Dead, Converted)
  • Assigned specialist/owner

3. Campaign Members (Attribution Layer)

• Link each Inbound Request to a Campaign for marketing attribution
• Use Campaign Member to track ROI per product/interest
• Maintain full marketing funnel visibility

How It Works

Scenario: Existing Lead Submits New Form

1. Web form submitted → Apex/Flow checks for existing Lead/Contact by email
2. Match found → Create new Inbound_Request__c record linked to existing Lead
3. Campaign Member created → Link to the campaign for this specific product
4. Assignment rules fire → Route Inbound Request to appropriate specialist based on product/service
5. Sales works the request → Specialist updates Inbound Request status, not Lead status
6. Conversion → When ready, use standard Lead Convert (or custom conversion for Contacts)

Benefits of This Approach

✅ No duplicate Leads

→ Single identity record per person 

✅

→ Original attribution stays intact 

✅

→ Each Inbound Request = one interest 

✅

→ Assignment rules on Inbound Request object 

✅

→ Campaign Members per request 

✅

→ Clear view of active vs. old interests 

✅

Object Schema

HTML

Lead/Contact (Identity)
├── Inbound_Request__c (Interest 1)
│   ├── Campaign_Member__c → Campaign A
│   ├── Product__c: "Service A"
│   ├── Status__c: "Dead"
│   └── Lead_Source__c: "Webinar 2024"
│
├── Inbound_Request__c (Interest 2)
│   ├── Campaign_Member__c → Campaign B
│   ├── Product__c: "Service B"
│   ├── Status__c: "New"
│   └── Lead_Source__c: "Web Form 2025"
│
└── Inbound_Request__c (Interest 3)
    ├── Campaign_Member__c → Campaign C
    ├── Product__c: "Service C"
    ├── Status__c: "Qualified"
    └── Lead_Source__c: "Referral"

Key Fields on Inbound_Request__c

FieldTypePurpose

Lead__c / Contact__c | Lookup | Link to identity record 

Product_Service__c | Picklist | What they're interested in 

Request_Status__c | Picklist | New, Contacted, Qualified, Dead, Converted 

Lead_Source__c | Text | Source for

request 

Campaign__c | Lookup | Marketing campaign attribution 

Assigned_Specialist__c | Lookup (User) | Who's working this request 

Request_Date__c | DateTime | When submitted 

Notes__c | Long Text | Specialist notes

Automation & Routing

1. Web-to-Lead/Web-to-Case Flow:

HTML

Web Form Submission
  ↓
Check for existing Lead/Contact (by email)
  ↓
If exists → Create Inbound_Request__c (linked to existing)
If new → Create Lead + Inbound_Request__c
  ↓
Create Campaign Member
  ↓
Assignment Rule: Route Inbound_Request to specialist based on Product__c
  ↓
Email notification to specialist

2. Lead Conversion:

• When specialist qualifies the request, they can convert the Lead (standard button)
• Post-conversion: Inbound Request links to the new Contact/Opportunity
• Historical requests remain visible on Contact record

Sales UX: What Reps See

Lead/Contact Record:

• Related List: "Inbound Requests" (all interests, current and historical)
• Quick view: Which requests are active vs. dead
• Original Lead Source preserved

Inbound Request Record:

• Clear status per interest
• Specialist assignment
• Campaign attribution
• Product/service details

Reports & Dashboards:

• Active requests by product
• Conversion rates per campaign
• Specialist workload
• Marketing ROI by product line

Marketing Attribution

Use Campaign Influence or custom reporting:

• Each Inbound Request → Campaign Member
• Track first touch, last touch, multi-touch attribution
• Report on ROI per product/campaign
• Maintain full funnel visibility

Alternative Considerations

Why NOT use Opportunities for this?

• Opportunities imply qualified sales stage
• Inbound Requests may be early-stage inquiries
• You want to track interest before opportunity

Why NOT use Cases?

• Cases are for support, not sales inquiries
• Doesn't integrate well with Lead conversion
• Marketing attribution is harder

Why NOT use multiple Leads?

• Fragments Customer 360 view (your concern)
• Breaks Pardot/Account Engagement scoring
• Creates massive data debt
• Duplicate management nightmare

Implementation Checklist

1. ✅ Create Inbound_Request__c custom object
2. ✅ Build web-to-lead/form handler (Apex/Flow)
3. ✅ Configure duplicate matching rules (Lead/Contact)
4. ✅ Set up assignment rules on Inbound Request
5. ✅ Create Campaign Member automation
6. ✅ Build related lists on Lead/Contact layouts
7. ✅ Train sales team on new process
8. ✅ Build reports/dashboards for visibility
9. ✅ Integrate with Pardot/Account Engagement

Copado DevOps Consideration

When deploying this solution through Copado:

• Metadata: Custom object, fields, flows, assignment rules
• Data: May need data templates for testing in sandboxes
• Testing: Use Copado Robotic Testing to automate form submission scenarios
• Quality Gates: PMD checks on Apex handlers, flow best practices

This architecture gives you the best of all worlds: clean data, proper attribution, sales efficiency, and the ability to use standard Salesforce features like Lead conversion. It's a proven pattern used by many organizations facing the same challenge.

Flow to Notify Case Team When New Case is Opened

Overview

This guide walks you through creating a Record-Triggered Flow that automatically notifies the Case Team whenever a new case is created in Salesforce.

Flow Configuration

1. Flow Type and Trigger Setup

Flow Type: Record-Triggered Flow

Object: Case

Trigger: A record is created

Entry Conditions:

• No additional conditions needed (triggers on all new cases)
• Alternatively, add conditions if you only want notifications for specific case types:
  • Example: Case.Priority EQUALS High
  • Example: Case.Status NOT EQUAL TO Closed

Optimize the Flow For: Actions and Related Records

Run: After the record is saved

Flow Elements

2. Get Records - Retrieve Case Team Members

Element Type: Get Records

Label: Get Case Team Members

Object: Case Team Member

Conditions:

• ParentId (Case ID) Equals {!$Record.Id}

How Many Records: All records

Store Output: Yes - Create a collection variable called varCaseTeamMembers

Fields to Store:

• MemberId (User ID)
• TeamRoleId
• Member.Email
• Member.Name

3. Decision - Check if Team Members Exist

Element Type: Decision

Label: Team Members Found?

Outcome 1: Yes - Team Members Exist

• Condition: {!varCaseTeamMembers} Is Null {!$GlobalConstant.False}

Default Outcome: No Team Members

• (Optional: You can add logging or alternative notification here)

4. Loop - Iterate Through Team Members

Element Type: Loop

Label: Loop Through Case Team Members

Collection Variable: {!varCaseTeamMembers}

Direction: First item to last item

5. Send Email - Notify Each Team Member

Element Type: Action - Send Email (or Email Alert)

Label: Send Notification Email

Recipient Email Addresses: {!varCaseTeamMembers.Member.Email}

Subject: New Case Opened: {!$Record.CaseNumber} - {!$Record.Subject}

Body (Plain Text or Rich Text):

HTML

Hello {!varCaseTeamMembers.Member.Name},
A new case has been opened and assigned to the Case Team:
Case Number: {!$Record.CaseNumber}
Subject: {!$Record.Subject}
Priority: {!$Record.Priority}
Status: {!$Record.Status}
Created Date: {!$Record.CreatedDate}
Case Owner: {!$Record.Owner.Name}
Description:
{!$Record.Description}
Please review this case in Salesforce:
[Link to Case: {!$Record.Id}]
Thank you,
Salesforce Automated Notifications

Alternative - Use Email Template:

• Create a custom Email Template for better formatting
• Reference it in the Send Email action

Best Practices & Considerations

Performance Optimization

• Bulkification: This flow is bulkified by default since it processes records individually but can handle bulk inserts
• Governor Limits: Be mindful of email limits (5,000 emails per day for standard orgs)
• Avoid Recursion: Since this triggers on create only, recursion isn't a concern

Enhanced Features You Can Add

1. Conditional Notifications

Add criteria to only notify for specific case types:

HTML

AND(
  OR(
    TEXT({!$Record.Priority}) = "High",
    TEXT({!$Record.Priority}) = "Critical"
  ),
  TEXT({!$Record.Status}) != "Closed"
)

2. Use Chatter Instead of Email

Replace the Send Email action with a Post to Chatter action:

• Target: Case record
• Message: "@{!varCaseTeamMembers.Member.Name} - New case assigned to team"

3. Create Task for Team Members

Add a Create Records element to create tasks:

• Object: Task
• Subject: "Review New Case: {!$Record.CaseNumber}"
• WhoId: {!varCaseTeamMembers.MemberId}
• WhatId: {!$Record.Id}
• Status: "Not Started"
• Priority: "Normal"

4. Use Platform Events for Scalability

For high-volume orgs, consider publishing a Platform Event instead of direct emails to avoid governor limits.

Alternative Approach: Email Alert (Simpler)

If you prefer a simpler approach without looping:

Create an Email Alert

1. Setup → Email Alerts → New Email Alert
2. Object: Case
3. Email Template: Select or create template
4. Recipients:
   • Add "Case Team" as recipient type
   • This automatically sends to all Case Team members

Create Process Builder or Flow

1. Trigger on Case creation
2. Add immediate action: Send Email Alert
3. Select the email alert created above

Testing Your Flow

Test Scenarios

1. Create a new case with Case Team members assigned
2. Verify emails are sent to all team members
3. Test with no team members - ensure flow doesn't error
4. Bulk test - create multiple cases simultaneously to verify bulkification

Debug Tips

• Enable Debug Mode in Flow Builder
• Check Email Logs in Setup → Email Log Files
• Review Flow Interview Logs for any errors
• Use Flow Fault Emails to catch runtime errors

Deployment Considerations

When Using Copado for Deployment

1. Commit the Flow to your user story
2. Include Dependencies:
   • Email Templates (if custom)
   • Custom Fields referenced in the flow
   • Case Team Member object permissions
3. Test in Lower Environments before production
4. Activate Flow only after successful validation
5. Document the flow purpose in the Description field for future reference

Required Permissions

• Users need Read access to Case Team Member object
• Flow runs in System Context by default (recommended)
• Email deliverability settings must be configured

Maintenance & Monitoring

• Monitor Flow Errors: Setup → Process Automation Settings → Enable Flow Fault Emails
• Review Email Deliverability: Check bounce rates and spam reports
• Update Email Templates: Keep messaging current with business needs
• Version Control: Use Copado to track flow changes over time

Summary

This Record-Triggered Flow provides automated notifications to Case Team members whenever a new case is created, ensuring immediate awareness and faster response times. The solution is scalable, maintainable, and follows Salesforce best practices for automation.

I'll help you design a robust credit/correction process for your Field Service setup. Based on Salesforce best practices and your specific requirements, here's my architectural guidance:

Recommended Approach: Separate Credit Object with Audit Trail

For your use case, I strongly recommend avoiding negative quantities and instead implementing a dedicated Credit/Correction object that maintains full historical integrity. Here's why and how:

Architecture Overview

Create a custom Work_Order_Credit__c object that references the original Work Order and tracks all correction details:

HTML

Work_Order_Credit__c
├── Original_Work_Order__c (Lookup to Work Order)
├── Credit_Type__c (Picklist: Full Credit, Partial Credit, Correction)
├── Reason__c (Picklist: Technician Error, Customer Request, Billing Adjustment, etc.)
├── Status__c (Picklist: Draft, Pending Approval, Approved, Rejected, Processed)
├── Approval_Date__c
├── Approved_By__c (Lookup to User)
├── Finance_Processed__c (Checkbox)
├── Finance_Processed_Date__c
└── Related Lists:
    ├── Work_Order_Line_Item_Credits__c
    └── Product_Consumed_Credits__c

Detailed Design Recommendations

1. Work Order Line Item Credits

Create WOLI_Credit__c junction object:

• Links to original WOLI
• Credit quantity/hours (positive number representing amount to credit)
• Reason for credit
• Maintains link to Asset (critical for your asset history requirement)

2. Product Consumed Credits

Create Product_Consumed_Credit__c junction object:

• Links to original Product Consumed record
• Credit quantity (positive number)
• Inventory adjustment flag (for future Inventory Management)
• Asset reference (if applicable)

Why This Approach is "Finance-Proof" and Inventory-Ready

✅ Advantages:

1. Complete Audit Trail: Original technician work remains untouched; all corrections are additive records
2. Asset History Integrity: Credit records maintain Asset lookups, so you can report:
   • Original work performed on Asset
   • Corrections/credits applied
   • Net labor/parts for Asset valuation
3. Inventory Management Compatible: When you implement Inventory:
   • Original Product Consumed = inventory deduction
   • Product Consumed Credit = inventory addition (return to stock)
   • No negative inventory transactions that confuse stock levels
4. Finance Reporting: Easy to generate reports showing:
   • Gross work performed
   • Credits applied
   • Net billable (even though you're non-billing, this helps cost accounting)
5. Approval Flow Ready: Credit object has its own lifecycle independent of completed Work Orders

❌ Why Negative Quantities Fail:

• Inventory systems typically reject negative stock movements
• Confuses reporting (is -5 a credit or a data error?)
• Asset history becomes unclear (did we remove parts or credit them?)
• Salesforce Field Service Mobile app may not handle negatives well

Approval Flow Design

Implement a simple approval process on Work_Order_Credit__c:

HTML

1. Technician/Dispatcher creates Credit record (Status = Draft)
2. Submit for Approval → Status = Pending Approval
3. Approval Process:
   - Approver: Service Manager (for credits <$500)
   - Approver: Finance Manager (for credits ≥$500)
4. Approved → Status = Approved
5. Finance exports via Report → Marks Finance_Processed__c = TRUE

Finance Report View: Create a report type: "Work Order Credits with Line Items" filtered by:

• Status = Approved
• Finance_Processed__c = FALSE

This gives Finance a clean export of unprocessed credits for ERP import.

Asset History & Valuation

To answer your question about Asset history:

Create a custom Asset History related list using a Lightning component or report that shows:

SQL

SELECT 
  WorkOrder.WorkOrderNumber,
  WOLI.LineItemNumber,
  WOLI.Quantity,
  ProductConsumed.QuantityConsumed,
  (SELECT Credit_Quantity__c, Reason__c FROM WOLI_Credits__r),
  (SELECT Credit_Quantity__c, Reason__c FROM Product_Consumed_Credits__r)
FROM Asset
WHERE Id = :assetId

This gives you:

• Original work: What the technician reported
• Credits applied: What was corrected
• Net result: Calculated field for true asset service history

Implementation Roadmap

Phase 1: Core Objects (Week 1-2)

• Create Credit object and junction objects
• Build page layouts and record types
• Create validation rules (e.g., credit quantity ≤ original quantity)

Phase 2: Approval Process (Week 2-3)

• Configure approval process
• Build email templates for approvers
• Create Finance report view

Phase 3: User Training & Rollout (Week 3-4)

• Train dispatchers/service managers on credit creation
• Train Finance on new export process
• Monitor first 20 credits closely

Phase 4: Inventory Prep (Future)

• Add inventory location fields to Product Consumed Credits
• Build "Return to Stock" automation
• Test with Inventory Management pilot

Real-World Example

Scenario: Technician reports 4 hours labor + 2 parts on Work Order WO-12345 for Asset A-5678. Finance later discovers only 3 hours were actually worked, and 1 part was defective (should be credited).

Without Credit Object (negative approach):

• Modify WOLI to 3 hours (loses history of original 4)
• Create Product Consumed with -1 quantity (confusing, may break inventory)
• Asset history shows 3 hours (not the full story)

With Credit Object (recommended):

• Original WOLI: 4 hours (unchanged)
• WOLI Credit: 1 hour credit, Reason = "Overbilling correction"
• Original Product Consumed: 2 parts (unchanged)
• Product Consumed Credit: 1 part, Reason = "Defective part"
• Asset history shows: 4 hours performed, 1 hour credited = 3 net hours
• Finance report shows both transactions for ERP reconciliation

Pros & Cons Summary

ApproachProsConsSeparate Credit Object

(Recommended) | ✅ Complete audit trail 

✅ Inventory-compatible 

✅ Asset history clarity 

✅ Approval flow ready 

✅ Finance reporting flexibility | ⚠️ More objects to maintain 

⚠️ Slightly more complex data model 

| ✅ Simpler data model | ❌ Loses original technician data 

❌ Inventory issues 

❌ Asset history unclear 

❌ Reporting complexity 

| ✅ Simplest approach | ❌ No audit trail 

❌ Compliance risk 

❌ Can't distinguish tech error from correction

Next Steps

1. Validate with Finance: Confirm the Credit object export format meets their ERP import needs
2. Prototype: Build Credit object in sandbox with 5 test scenarios
3. Asset History Mock-up: Show stakeholders how Asset history will look with credits
4. Inventory Team Input: If you have inventory stakeholders, get their review now
5. Pilot: Run parallel (old manual process + new Credit object) for first month

@Nabina Roy​ 

Hi, To use Tabcmd, you must use Tabcmd 2.0 (I guess you are using it)

https://tableau.github.io/tabcmd/docs/

Are you trying to login using username and password?. If this is the situation, for Tableau Cloud you should use PAT.

https://help.tableau.com/current/online/en-us/security_personal_access_tokens.htm

and also, you should use it in tabcmd:

https://tableau.github.io/tabcmd/docs/tabcmd_cmd.html#login

If this post resolves the question, would you be so kind to "Select as Best"?. This will help other users find the same answer/resolution and help community keep track of answered questions. Thank you.

Regards,

Diego Martinez

Tableau Visionary and Forums Ambassador

@Zeke Camusio​ 

Hi, in this case you have two scenarios. The first one is the one you already have, and you don't need anything else.

Your published data sources already have RLS implemented

In this case, when you generate the JWT, you have to make sure to create it using the tableau user which already have the RLS configured in your data sources/workbooks (no need to encode attributes in your JWT):

import jwt
 
token = jwt.encode(
{
"iss": connectedAppClientId,
"exp": datetime.datetime.utcnow() + datetime.timedelta(minutes=5),
"jti": str(uuid.uuid4()),
"aud": "tableau",
"sub": user,
"scp": ["tableau:views:embed", "tableau:metrics:embed"],]
},
 
connectedAppSecretKey,
algorithm = "HS256",
headers = {
'kid': connectedAppSecretId,
'iss': connectedAppClientId
}
)

In this case, the session will be signed in with the user you have used in the sub clause (sub: user). So, if you have already configured RLS in your data sources, then wonderful, RLS will keep working as usual.

You want to pass info from your app, to the Tableau workbook

User Attribute Function are a great way to communicate info from your web app to Tableau. The examples you would find in Tableau would include a Region attribute, but other options is that you could pass a number (budget, or a goal), you could pass a text (description of the team, position, a URL to load the picture of the person).

If you use that info as a RLS or in a calculated field or as an image role, that depends on your dashboard and the use case you want to give to the info. You can retrieve the info with UAFs from the JWT you created.

If your RLS does not depend on info stored in your Web App ((i.e you are using an entitlement table, or user filters already built in your data sources, or Virtual Connections with policies), then I don't think you should use JWT with extra attributes and UAFs

If this post resolves the question, would you be so kind to "Select as Best"?. This will help other users find the same answer/resolution and help community keep track of answered questions. Thank you.

Regards,

Diego Martinez

Tableau Visionary and Forums Ambassador

• First create a new workbook...it must have some sort of data source but doesn't need to be real data
• Within the workbook, create a calculated field called 'Header' with 'Click link below to view report' as the Calculation body

• Drop the newly created Header field on the Text mark (may need to adjust font of Header i.e. larger and bold)

• Publish this workbook (Note: the name of the View will appear in the subscription email)
• Go to the actual report you want to share and copy the share link

• Go to the published version of the Header view and Subscribe to the View

• Subscribe the appropriate users, Edit Subject accordingly (Subject name will appear in the email), paste the copied Share link in the Message (I like to add "Report link:" before the Share link) and finally set the subscription schedule

• Users will receive an email that looks like this:

• Unfortunately Tableau disabled HTML subscription messages a few versions of Tableau Server/Online ago. Previously, we could create really nice custom massages without the default Tableau content. Hopefully they bring back HTML messages someday but "Security" was cited so it's probably a done deal.

RESOLVED! Mine was an issue with the URL. When I copied and pasted the URL into my Desktop Tableau, I pasted the entire URL with a fully qualified domain name:

https://server.company.com/#/views/workbook...

It works there because it has to cross server boundaries, BUT when I move it to the online server, I have to edit the URL to REMOVE part of the domain:

https://server.company.com/#/views/workbook...

It is now:

https://server/#/views/workbook...

This is because it is all on the same server. (I am going to assume if someone held dashboards on another server, they would need to include the entire fully qualified domain name.)

Hi,

Have a look at the documentation of the Tableau Javascript API; this will help you embed a Tabelau visualisation on a webpage, even on different domains.

Tableau JavaScript API - Tableau

You can do some really nice stuff with it!

Kind regards,

Johan de Groot

You need to change Email Attachment settings.  

Go To

New Setting:

Click

. 

-

Hi @Rosendo Silva

- This is a known quirk in Marketing Cloud when Engagement Split loses its saved link reference. 

Things that usually prevent it:

• Publish the email before linking 
  – Make sure the email is fully published (not just saved) and you’re selecting the latest published version when configuring the split.

• Use a stable link alias 
  – Every link you track needs a unique, lowercase alias in the HTML. If the alias is changed later or reused elsewhere, the split can’t find it and the config disappears.

• Avoid moving or renaming assets 
  – Don’t move the email to another folder or rename it after it’s referenced in a journey. That breaks the stored path.

• Clear cache / re-open journey carefully 
  – Edit the journey in a fresh browser session or incognito window and save/activate again. Some users report that stale browser cache causes the UI to drop the link on reopen even though the backend still tracks it.

If none of this stabilizes the configuration, open a Salesforce Marketing Cloud support case.