#Data Management108 discussing

Short answer: you generally cannot (and do not need to) write QuoteAccountId into the standard Quote.AccountId field. On the Quote object, AccountId is a system-derived, read-only reference that Salesforce fills from the related Opportunity's Account. It is not createable/updateable through the UI, Flow, Apex or the API, so an update like AccountId = QuoteAccountId will be rejected or ignored. For quotes created without an Opportunity, QuoteAccountId (label "Account for Quote") is the field Salesforce intends you to use as the account relationship. 

For your future Order process this is already covered: Salesforce's documentation for quotes without opportunities says associating the quote to an account is optional but recommended, because an account is required to convert the quote to an order. When you create an Order from such a quote, the account comes from the quote's account (QuoteAccountId), so you don't need Quote.AccountId populated. 

Practical recommendations: 

1. Make QuoteAccountId required (validation rule, e.g. ISBLANK(OpportunityId) && ISBLANK(QuoteAccountId)) so every quote can be turned into an Order. 

2. After enabling the feature, open Object Manager > Quote > Fields > Account for Quote and grant field-level security to your profiles/permission sets. It is hidden by default, which is why it often looks unavailable in Flow, reports and Apex. 

3. In reports, flows, sharing logic and Apex, use one source of truth, for example a formula field BLANKVALUE(QuoteAccountId, Opportunity.AccountId), so logic works for quotes with and without an Opportunity. 

4. If you create Orders yourself via Flow/Apex (rather than the standard Create Order action), set Order.AccountId = Quote.QuoteAccountId and Order.QuoteId = Quote.Id. 

References: 

Enable Quote Creation Without a Related Opportunity:

Release note, Create Quotes Without a Related Opportunity:

Quote object reference:

Assumption: the statement that Quote.AccountId is read-only is based on the Quote object reference field properties and commonly reported org behaviour; please confirm in a sandbox (e.g. attempt the update in a Flow or Developer Console) before designing around it.

To migrate from Rackspace to Gmail

, you can manually transfer emails using an IMAP-supported email client like Outlook or Thunderbird. However, moving large mailboxes folder by folder can be time-consuming. 

For bulk migration, use

. It lets you select specific folders, apply date filters, transfer multiple Rackspace accounts & preserve emails, attachments, formatting & folder hierarchy while moving data to Gmail. 

Steps: Add your Rackspace account → select folders → choose Gmail as the destination → sign in to Gmail → start the migration.

Hi Eduardo,

If you're using the Salesforce PHP Toolkit, you can control this with the SOAP API AllOrNoneHeader. 

By default, the API can roll back the entire create() operation when one or more records fail. If you want successful records to be committed while only the failed records are returned as errors, set allOrNone to false. 

For example, depending on the PHP Toolkit version, the call is typically along these lines:

$result = $client->create($records, array('AllOrNoneHeader' => array('allOrNone' => false))); 

The exact method signature can vary between PHP Toolkit versions, so check the generated SforceClient method for API v20. 

If you want the whole batch to succeed or fail together, leave allOrNone as true. 

Hi Brian,

Unfortunately, the standard Field History Tracking feature doesn't maintain a separate, permanent audit history showing when each individual field was enabled or disabled for tracking.

The Setup Audit Trail is the main standard place to identify configuration changes, but as you mentioned, its retention is limited. Exporting it periodically is one way to retain that history longer.

If you need a permanent audit of tracking configuration changes, you'd generally need to maintain it outside the standard Field History Tracking mechanism—for example, by periodically exporting the Setup Audit Trail or using a custom/configuration-management process.

Looking at the first and last history records for a field won't reliably identify gaps, so I wouldn't recommend that as an audit method. 

Hi Connee,

I would recommend creating a Vendor custom object to store the vendor information, rather than entering the vendor details directly on each Lead or Opportunity.

Then create Lookup relationships from the relevant records to Vendor, for example:

• Lead → Vendor
• Opportunity → Vendor
• Project → Vendor

For the service/good cost, you can add a Cost/Currency field on the related record or, if a project/opportunity can have multiple vendors or services, create a child object such as Vendor Cost with fields for Vendor, Service/Product, Quantity, Unit Cost, and Total Cost.

This structure will make it much easier to report on vendor spending by Lead, Opportunity, or Project.

If you describe how many vendors/services can be associated with each record, I can suggest the simplest object structure. 

Hi Aslam,

HttpRequest doesn't have a special "FORM" authentication scheme. The Authorization header you're creating is not a standard way to perform form-based authentication.

If the .NET service is using browser-style form authentication, you generally need to:

1. Make an initial POST to the login/authentication endpoint with the username and password in the format expected by the service.
2. Read the authentication cookie/token returned by that request.
3. Send that cookie/token with the subsequent request to the .asmx service.

For example, if the service uses a session cookie, the flow would be:

Login request → Set-Cookie → SOAP request with Cookie header

The exact implementation depends on how the .NET application implements authentication. If you can provide the login URL and an example of the HTTP request/response from a browser or tool such as Fiddler, it should be possible to determine exactly what needs to be sent from Apex.