* Data 360 *

Hi @Patrik Lundgren

, 

Notebook AI itself isn't well documented for the RFP use case specifically, but here's what I can piece together plus some alternatives worth considering. 

What Notebook AI actually is: It's a Data 360 (formerly Data Cloud) feature a workspace where you connect content sources (files, SharePoint, Salesforce data) and an underlying Agentforce Employee Agent gets auto provisioned to answer questions grounded in that connected content. This agent is meant to be used only within the Notebook AI workspace itself the required variables, context, and libraries are configured there, and even though it shows up under Agentforce Agents, using or creating it directly from that list isn't supported and can behave unexpectedly. The intended pattern is connecting a native Data 360 search index (e.g. a SharePoint vault) so it stays synced, then having an Agentforce agent run in the background detecting new documents, reading them, and triggering downstream actions like alerts. 

For an RFP Agent specifically, that maps reasonably well conceptually: you'd feed Notebook AI your past proposal answers, product docs, pricing sheets, and case studies as connected sources, and it could research/answer questions against that corpus. But I didn't find anything from Salesforce documenting a concrete RFP-specific workflow or template beyond it being listed as a use case no worked example, no reference architecture for that scenario specifically. 

Purpose-built alternatives if Notebook AI's docs stay thin, several vendors already build RFP-response tooling natively into Salesforce: 

• Inventive AI generates opportunity-aware RFP responses using historical answers and connected content, syncing details, timelines, and status back to the Opportunity, with a widget addable to the Opportunity record page via Lightning App Builder.
• AutoRFP.ai installs as an AppExchange managed package, creating a custom RFP project object with two-way sync to Opportunities status, response counts, due dates.
• GPTfy documents a five phase Salesforce+AI RFP process (Intake, Analysis, Preparation, Review, Approval) with routine-question automation and confidence scoring for review focus.

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too. 

The key condition you’re missing is that Salesforce Data Cloud related lists are only supported for ingested DMOs that have undergone identity resolution and are tied to the Individual DMO. Zero Copy sources can be mapped and unified, but they do not

currently support related lists on CRM page layouts. 

Why Zero Copy Doesn’t Work for Related Lists

• Zero Copy = Federation, not ingestion
  • Data Cloud registers external tables as Data Lake Objects (DLOs) and queries them in place. 
  • The data stays external; only metadata and query paths are stored.
• Related lists require ingested DMOs
  • Related lists on CRM page layouts depend on identity resolution and relationships built on ingested DMOs.
  •  Federated (Zero Copy) DMOs don’t materialize inside Data Cloud, so they cannot be surfaced in related lists.
• Supported downstream features
  • Zero Copy DMOs do work for segmentation, calculated insights, and identity resolution.
  • They don’t support related lists or page layout rendering because those require local object materialization.

Glad to help! If this answers your question, please consider marking it as the Best Answer—it helps others in the community find the solution more easily. Thanks!

Hi Juan Pablo, 

Great diagnosis — and yes, this is the actual (if under-documented) mechanics of Streaming Data Transforms. 

Answering your three questions: 

1. Is this documented? Not explicitly with this framing, but it follows from how SDT works under the hood: it behaves like a continuously materialized view keyed on the target Primary Key, not a simple append/insert stream. The engine treats your target PK (id__c/cookie__c) as "the current state for this key, per the transform's SQL definition." When a new source event arrives for that same key and no longer satisfies the WHERE clause, the engine's correct answer to "what does the view look like now for this key?" is "nothing" — so it retracts/deletes the previously materialized row. This is standard streaming materialized-view semantics (the same pattern you'd see in Spark Structured Streaming or ksqlDB), not a bug or hidden special case. 

2. Can you make it append-only without a composite key? Not with a single business-key PK feeding a filtered SELECT — the moment your target PK is purely the business key, the transform is inherently a stateful "latest matching state per key" view, and any later event for that key that fails the filter will retract it. Your composite key fix (cookie + type) is exactly right, because it changes the semantic from "current login state per cookie" to "did this cookie ever have a login event" — each (cookie, type) pair becomes its own independent, append-safe row that no other event can invalidate. 

3. Does it track state even though the source is Engagement-categorized? Yes — the Engagement categorization on the source DLO governs retention/volume handling on the source side, but it doesn't change the transform engine's need to maintain per-target-key state to know whether to insert, no-op, or retract on each new source event. 

So: not a "silent deletion" bug — it's the expected behavior of a stateful streaming view keyed on a business key with a filter, and composite keys are the documented-by-implication way to avoid it. 

Reference:

Good instinct isolating this via the composite key — that's the standard pattern for exactly this scenario.

Thank you for your detailed answers, guys! 

Actually, I had just added a stream and DMO mapping, then tried Identity Resolution only. I deleted that after testing, and nothing else was left. I checked each and every tab, nothing was there. It just wouldn't let me delete that relation. 

After trying multiple ways, I found an option in the data model to edit the category. I switched it to "Other," and after that I was able to delete it since the primary key logic became invalid. It looks like a technical glitch, nothing was actually connected. 

Thanks again for your help!