#Salesforce Developer444 discussing

Hi @Yalamanchili Naga Sajitha

, 

What’s wrong with the snippet 

• icadjust.clone() only copies the list in memory and discards the result. It doesn’t save anything.
• Setting c.Type__c = ... on a queried record only changes the in-memory copy. CMDT records can’t be updated or inserted with DML.
• [type.id](https://type.id/) is a paste artifact. It should be type.Id.

// 1. Query the source child records, including every custom field you want copied
List<child__mdt> source = [
    SELECT DeveloperName, MasterLabel, Type__c, Other_Field__c
    FROM child__mdt
    WHERE Parent__r.Label = 'Test record'
];
// 2. Get the target parent (the relationship value is based on DeveloperName, not Id)
Parent__mdt target = [SELECT DeveloperName FROM Parent__mdt WHERE Label = 'Test rec' LIMIT 1];
// 3. Build new CMDT records
Metadata.DeployContainer container = new Metadata.DeployContainer();
for (child__mdt c : source) {
    Metadata.CustomMetadata md = new Metadata.CustomMetadata();
    String newName = target.DeveloperName + '_' + c.DeveloperName;   // DeveloperName must be unique
    md.fullName = 'child__mdt.' + newName.left(40);                  // keep within the name length limit
    md.label = c.MasterLabel;
    // Reparent via the relationship field
    Metadata.CustomMetadataValue parentVal = new Metadata.CustomMetadataValue();
    parentVal.field = 'Parent__c';
    parentVal.value = target.DeveloperName;
    md.values.add(parentVal);
    // Copy the other fields
    Metadata.CustomMetadataValue typeVal = new Metadata.CustomMetadataValue();
    typeVal.field = 'Type__c';
    typeVal.value = c.Type__c;
    md.values.add(typeVal);
    // ...repeat for each remaining field
    container.addMetadata(md);
}
// 4. Deploy (asynchronous)
Id jobId = Metadata.Operations.enqueueDeployment(container, null);
System.debug('Deployment job: ' + jobId);

Things to watch 

• The deployment is asynchronous. Check progress in Setup > Deployment Status, or pass a Metadata.DeployCallback as the second argument to log success or failure.
• Query DeveloperName and MasterLabel, not just Id, since the deployment is keyed on fullName.
• The format for a metadata relationship value (plain parent DeveloperName versus ParentType__mdt.DeveloperName) is something I haven’t verified against your org. If the deploy fails with a relationship error, try the qualified form.
• This relationship field is technically a Metadata Relationship, not a true master-detail. It behaves similarly but doesn’t cascade-delete the same way.
• Run this in a sandbox first, then deploy to production through your normal path.

Easier no-code alternatives, if this is a one-off

• Export the 40 child rows via Workbench or Data Loader-style tooling. You can also retrieve them with sf project retrieve start -m CustomMetadata:child.*.
• Then copy and rename the .md-meta.xml files and update the parent reference.
• Redeploy with sf project deploy start. This is often the fastest option for a small, one-time copy.

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

Hi @Galla Rajeswari

Sandbox-to-production failures with Agentforce are almost always about identity, data and unmigrated dependencies, not the agent logic. Here is the process I’d use. Exact tool names (Testing Center, Command Center, and so on) change between releases, so verify them against the current release notes. 

1. Pre-go-live checks (before users touch it) 

 Before an Agentforce agent goes live in production, check these six things. 

Deployment: Make sure the agent, its topics, actions, and prompt templates are all deployed, and that the correct agent version is activated. Any Apex or Flow actions, custom fields, and invocable references the agent uses must also exist in production. 

Running identity: The agent’s running user (or the agent user, for service agents) needs the right permission sets, object and field access, and access to the relevant Apex classes and Flows. Missing permissions are the most common reason an agent “worked in sandbox” but fails in production. 

End-user access: For employee-facing agents, test with a real user profile, not only as an admin. This way sharing rules and field-level security are actually tested. 

Grounding data: Data 360/Data Cloud, Knowledge articles, and data categories must exist and be indexed in production. Metadata deployment often doesn’t carry these over. 

Channel configuration: Confirm that Messaging and Omni-Channel routing, escalation flows, queues, embedded deployment URLs, and CORS settings are correct for production. 

Integrations: Check that Named Credentials, external services, and endpoints point to production systems and not leftover sandbox ones. 

2. Validation tests in production 

• Batch-test utterances with the agent testing tool. Cover each topic with expected topic, expected action, and expected outcome, plus negative cases (out-of-scope, ambiguous, adversarial).
• Run the same test suite in sandbox and prod and diff the results, so you separate platform differences from agent differences.
• Test action execution end to end: confirm records are actually created or updated, not just that the reply sounds right.
• Test data access boundaries. Ask as a low-privilege user for data they shouldn’t see and confirm the agent refuses or returns nothing.
• Test escalation and fallback: handoff to a human, behavior when an action fails, and behavior when grounding returns nothing.

3. Monitoring after launch 

• Agent analytics/observability dashboards: track topic distribution, action success/failure rate, escalation rate, and unresolved conversations.
• Session tracing/audit trail (via the Trust Layer and Data 360 where enabled): review a sample of real conversations weekly to catch drift, wrong topic selection, and hallucinated answers.
• Underlying automation logs: Flow fault emails and Apex debug logs filtered to the agent’s running user. Most “agent bugs” are actually a failed Flow or Apex action.
• User feedback (thumbs up/down) reviewed regularly.
• Alert thresholds, for example on action error rate or a spike in escalations or “can’t help” responses.

4. Operational habits that help 

• A smoke test suite of 10 to 20 critical utterances run after every deployment, and again after each Salesforce seasonal release, since model and platform behavior can shift.
• Phased rollout to a pilot group before full launch.
• A rollback path, meaning the previous agent version stays available to reactivate.
• Update topic and instruction wording from real conversation logs, not just from pre-launch assumptions.

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

Hi@Galla Rajeswari

LWC stays important, and AI mostly raises the value of understanding it rather than replacing it. This is a practitioner view from the Salesforce side; I haven’t searched for current Trailblazer thread replies, so treat it as my reasoning rather than a survey of community opinion.  

Why AI doesn’t remove the need 

AI is good at generating a component that looks right. It is much weaker at knowing whether that component is right for your org. The gap shows up in a few places: 

• Platform-specific behavior. The Lightning Data Service cache, wire adapter reactivity, refreshApex, and Lightning Web Security vs. Locker all have quirks. Generated code often compiles and renders but misbehaves with real data or in a second context.
• Security and sharing. Whether an Apex method behind a component enforces CRUD/FLS and with sharing is something AI frequently gets subtly wrong. Someone has to review it, and that requires knowing what correct looks like. This matters most in Experience Cloud, where a mistake can expose data to Guest Users.
• Performance at scale. Chatty server calls, unbounded queries, and re-render loops don’t show up in a demo but do in an org with real data volumes.
• Accessibility and design system conformance. SLDS, keyboard navigation, and screen reader behavior are easy to get plausibly wrong.
• Maintainability. Code the team can’t read or debug becomes technical debt the moment the person who prompted it moves on.

Where LWC adds the most value that AI can’t easily replace

1. Reviewing and owning generated code. The skill shifts from typing components to judging them. You can’t catch a wrong wire usage or a missing error path if you don’t know the framework.
2. Component architecture. Deciding how components communicate (events, LMS, parent-child), what state lives where, and what should be reusable is a design judgment tied to the client’s context.
3. Integration with the rest of the platform. LWC rarely stands alone. It sits on top of Apex, Flow, record pages, and sharing rules, and the hard part is making all of those behave together.
4. Agentforce UI surfaces. Custom actions and components that surface AI output inside Salesforce still need developers who can build and debug them. More AI features means more custom UI around them, not less.
5. Debugging real-world failures. When something breaks in a specific org with specific data and permissions, you need to read the code and the platform, not just re-prompt.

Where the role does change

• Boilerplate (forms, simple datatables, standard CRUD screens) is increasingly generated or replaced by declarative tools like Screen Flows and Dynamic Forms. Spending your career hand-writing those is the part at risk.
• Developers who only translate specs into basic components will feel pressure. Developers who combine LWC depth with data model, security, and architecture judgment become more valuable.

Practical advice for the next five years

• Learn the LWC fundamentals deeply enough to review AI output critically (reactivity, wire vs. imperative Apex, LDS, event model, LWS).
• Use AI to move faster on the boring 70%, and spend your saved time on testing, security review, and accessibility.
• Pair LWC skill with Apex, Flow, and Agentforce knowledge. The “full-stack on Salesforce” developer is the hardest to replace.
• Prefer declarative options first, and write LWC where it’s genuinely needed. Knowing when not to build a component is part of the skill.

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

Hi @Souvik Dutta, this looks like an extension version mismatch rather than a Salesforce config issue. showCommandWithTimestamp

is not a function is an internal output-channel helper, so the Apex OAS extension is calling a method that the other extension doesn’t have in that build.  

Your project.json and settings.json changes look correct. The likely cause is the Agentforce Vibes downgrade to 3.40. The OAS feature uses Vibes for the LLM call, so it can go out of sync with the newer Salesforce extensions.  

Things to try: 

1. Update Agentforce Vibes and the whole Salesforce Extension Pack to the latest matching versions, then run “Developer: Reload Window”. Please share the exact 4.x error if it still fails.
2. Test in a clean VS Code profile with only the Salesforce Extension Pack, using a minimal @RestResource class.
3. Check VS Code → Output (Apex OAS and Agentforce Vibes channels) and note the exact extension versions.
4. If it still fails with matching latest versions, report it at github.com/forcedotcom/salesforcedx-vscode with the logs and versions.

As a workaround, you can write the OpenAPI YAML manually under externalServiceRegistrations/

and deploy it. 

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

Hi @Galla Rajeswari Deploying Agentforce to production can be tricky, especially when multiple subagents and actions are involved.

I would check these key points:

1. Dependencies: Make sure all Flows, Apex classes, and Prompt Templates are deployed.
2. Subagents & Actions: Verify all subagents and actions are properly configured.
3. Permissions: Check the agent running user's access, object permissions, and field access.
4. Agent Version: Confirm the correct version is active.
5. External Connections: Verify APIs, Named Credentials, and authentication.
6. Data Differences: Production data may affect agent responses differently.
7. Testing: Check subagent routing, action execution, and response accuracy.
8. Deployment Errors: Watch for missing components and activation issues.

I would recommend testing with a small group of users before making the agent available to everyone.

Key Point: A successful deployment doesn't mean the agent is ready. Proper testing and monitoring are equally important.

@Roopa Sharma, This is a good area to learn early. Many orgs end up with documents in both systems, and the friction shows up exactly where you listed. Here is how each one tends to play out once a setup is live.  

1. Where the documents live - 
   • SharePoint as the home, with Salesforce records pointing to it. The usual choice when the company already runs on Microsoft 365.
   • Salesforce Files, when volumes are small and only CRM users need the documents. The Files related list is flat, with no folders per record.
2. Ways to connect the two
   • Files Connect (native): lets users browse, search and attach SharePoint files from Salesforce, but it does not create a folder per record.
   • Power Automate: a good fit if your team already builds on the Microsoft side. The trade-off is that the logic lives outside Salesforce, on a premium connector. 
   • AppExchange apps: compare them on four things. Does Flow create a folder when a record is created? Do uploads from the record go straight to SharePoint? Do SharePoint's own permissions still apply? Can you trial it in a sandbox first? 
3. Your questions, in practice - 
   • Folder structure: mirror your data model (Account, then Opportunities, then each opportunity), with the same subfolders on every record. Add the record ID to folder names so a rename never breaks a link. 
   • Metadata: tag files with SharePoint columns such as document type, status and record ID, instead of relying on folder names.
   •  Version control: let SharePoint's version history handle it, and avoid saving copies back into Salesforce. 
   • Security: SharePoint decides who can open a file. Salesforce sharing does not carry over to SharePoint on its own, so plan who updates access when an account changes owner.
   • User experience: users should reach a record's folder from the record page, without searching SharePoint.

If you go the AppExchange route, CloudFiles is one app that works this way with SharePoint. With its flow actions, each record gets a folder when it's created, and files are tagged as they arrive. Users open that folder from the record page, and SharePoint's permissions decide what each person can see. https://appexchange.salesforce.com/appxListingDetail?listingId=a0N4V00000Gh9uFUAR

Disclosure: I work at CloudFiles.

This typically occurs because the automated scoring package or managed flow tries to execute synchronously on newly inserted Opportunity or Contact records simultaneously with the GoFundMePro data sync. When high-volume or third-party payment integrations push records into your instance, the sudden influx of DML operations can cause lock contention or trigger depth limits, causing the scoring flow or trigger to fail before it can evaluate the $100 and 999-day threshold criteria. 

To resolve this, you should refactor or transition the scoring logic into an asynchronous process, such as a Queueable Apex job or a scheduled batch process, rather than letting it fire on immediate after-insert triggers from the payment portal. This decouples the GoFundMePro gift ingestion from the resource-intensive iWave scoring callouts, ensuring the donations sync cleanly first without being blocked by subsequent processing errors. 

Additionally, review the error logs in your Setup under Apex Exceptions or Process Automation Failures to identify the exact failing element. Adding explicit null checks and bulkified try-catch blocks within your wrapper handler will also prevent third-party integrations from stalling when missing secondary related fields during creation.