Feed

Hi , 

 You'll need to create a custom permission set that contains that custom permission.  

https://help.salesforce.com/s/articleView?id=000386266&type=1

AND( 
  OR(    
    ISNEW(), 
    ISCHANGED(Email), 
    ISCHANGED(Phone) 
  ), 
  ISBLANK(Email), 
  ISBLANK(Phone),
  NOT($Permission.Custom_Permission_Name)
)

https://salesforce.stackexchange.com/questions/239262/using-permission-set-in-validation-rule

This is the correct way to solve for this.  

SELECT individual.ssot__FirstName__c,  

    account.ssot__AnnualRevenueAmount__c  

FROM ssot__Individual__dlm individual  

INNER JOIN ssot__Account__dlm account  

    ON individual.ssot__PrimaryAccountId__c = account.ssot__Id__c  

WHERE account.ssot__AnnualRevenueAmount__c > 500000000 

The 'Migrate to External Connected App' is available/used to migrate a Connected App to an ECA.  Neither of these are SOAP-based/related, they are both for OAuth.  SOAP login uses a completely different authentication process (SOAP request to Enterprise/Partner endpoint).  For each application integration, the code in the integration will need to be updated to switch from SOAP to OAuth using an ECA defined for that integration (or set of integrations, if the requirements are consistent).  Ideally your vendor will be providing transition documentation with the particulars of migrating their integration from SOAP to OAuth.  If it is custom code that you own, then you have some development activity ahead of you.  In terms of end-users, they would only be impacted if they are using an application that does the login using SOAP (e.g. a dialog that takes username/password/secret), it would switch to an OAuth-based login (for an example, look at more recent versions of DataLoader where there is a choice between the two).  For back-office/server-side applications, they would also migrate to an OAuth authentication flow with associated configuration (again, depending on the application and OAuth requirements).  Clear as mud?

Hi , 

To address the issue, I had to manually update the agent script and enter input and output data types for the Finalize Reservation action:  

FinalizeReservation:
            description: "Books and finalizes a reservation for the time designated by the customer."
            label: "Finalize Reservation"
            require_user_confirmation: True
            include_in_progress_indicator: True
            source: "SvcCopilotTmpl__FinalizeReservation"
            target: "flow://SvcCopilotTmpl__FinalizeReservation"
            inputs:
                "contactRecord": object
                    description: |
                        The contact record associated with the identified customer.
                    label: "Contact record"
                    is_required: True
                    is_user_input: False
                    complex_data_type_name: "lightning__recordInfoType"
                "dateTime": datetime
                    description: |
                        Stores the date and time of the customer's reservation.
                    label: "Date time"
                    is_required: True
                    is_user_input: False
            outputs:
                "outcomeMessage": string
                    description: |
                        Stores the message that lets the customer know whether the reservation was successfully finalized.
                    label: "Outcome message"
                    is_displayable: True
                    filter_from_agent: False

Hi , 

1. From the App Launcher, find and select Agentforce Studio, then click Agents.
2. In the All Agents list on the Agents page, find the row for the agent you want to delete. Open the dropdown menu and select Delete Agent. After an agent or agent version is deleted, it can’t be recovered.

Agents from the legacy may appear in the agents list with the Delete

button disabled. Legacy agents must be deleted from the legacy builder. 

https://help.salesforce.com/s/articleView?id=ai.agent_versions_delete.htm&type=5

@Marcos Gomes

In my opinion, governance should come before autonomy. Agentforce is only as reliable as the data and permissions it is given.

A practical approach is:

• Clean legacy data first by removing duplicates, standardizing values, archiving obsolete records, and defining data quality rules.
• Implement strong data governance with clear ownership, validation rules, monitoring, and regular data quality reviews.
• Apply least-privilege access so AI agents only access the data they genuinely need. Sensitive fields should be protected with Field-Level Security, Permission Sets, Shield Platform Encryption, and Data Cloud data policies where applicable.
• Establish trust boundaries. Don't allow autonomous agents to perform high-risk actions without human approval. Critical decisions (pricing, financial updates, customer record changes, etc.) should include approval workflows or human-in-the-loop checkpoints.
• Continuously monitor and audit agent activity using logs, event monitoring, and feedback loops to identify incorrect decisions and improve prompts, policies, or data quality.

Ultimately, successful Agentforce implementations depend less on the AI model itself and more on the organization's data quality, governance framework, and security controls. Clean, governed, and well-permissioned data is what enables AI agents to make trustworthy decisions.

A 404 on session creation is a known Agent API issue. Per Salesforce's troubleshooting guide, the likely causes are: 

1. Agent ID mismatch — if the agent was built in the newer Agentforce Builder (not legacy Bot Builder), the ID shown in the builder URL often isn't the ID the API expects. You may need to query BotDefinition via SOQL (SELECT Id, DeveloperName FROM BotDefinition) to get the right Id — see Salesforce's guide: developer.salesforce.com/docs/ai/agentforce/guide/agent-api-agent-id.html. Assumption: since it's called a "Knowledge Agent" and is Active, I'm assuming it was built in the newer builder — if so, this is the most likely culprit.
2. The default "Agentforce (Default)" agent type isn't reliably supported by the Agent API — only custom agents built for API access tend to work.
3. If the org is on Government Cloud, the host must be api.gov.salesforce.com, not api.salesforce.com.
4. The endpoint path (/einstein/ai-agent/v1/agents/{agentId}/sessions) matches Salesforce's documented endpoint at developer.salesforce.com/docs/ai/agentforce/guide/agent-api-get-started.html, so it's most likely the agentId value that's wrong.

Also: the "Runtime Base URL" on the ECA detail page is internal, not meant to be called directly. 

To isolate this quickly, Salesforce's official Postman collection for the Agent API is here:

— import it, plug in your consumer key/secret and domain, and test session creation directly to confirm whether it's the Agent ID or something else.