Admins / Consultants / Sales Cloud

Can OpenAI’s Operator Handle Salesforce Admin Tasks?

By Andreea Doroftei

The conversation about AI agents and their capabilities is at an all-time high, with innovations and new products appearing seemingly every day, stirring interest and curiosity across all industries. For Salesforce professionals, these innovations can represent a way to optimize productivity, increase efficiency, and completely transform the way they perform some of their day-to-day tasks. However, scalable implementations, knowing to make corrections as needed, and following best practices should remain top of mind.

In this post, we’ll explore whether and how a few of the most common Salesforce Administrator tasks can be performed by the new OpenAI Operator Agent.

Getting Started

OpenAI Operator was launched at the end of January 2025. It is an agent that works on a remote web browser by clicking, scrolling, and typing. The product is currently in research preview and available for ChatGPT Pro users in the United States. 

While its reasoning capabilities allows it to self-correct, it will either ask clarifying questions, request confirmation, or give users control when it encounters blockers or when the instructions given by users don’t match the instructions on the screen, for example. As you will see in the use cases below, the user can also take control back at any time or provide further instructions as needed.

When it comes to tasks involving sensitive information – such as logging in, inputting payment details, or completing CAPTCHAs – OpenAI Operator will proactively give control of the remote browser to the user to complete the step. No screenshots are taken during this time, and when you return control to Operator, you can optionally inform it of any actions or changes for context. If you’d like to try it yourself, be sure to review the safety and privacy information shared by OpenAI. 

Keep in mind that while it can already perform a range of tasks, it is still in its early stages and may make mistakes. However, since you have the option to monitor the task execution in real time and can take control, you can correct it as needed. For the use cases we’ll present, Operator will attempt to perform the tasks in a Developer Edition.

Create New Fields

Creating fields in Salesforce’s user interface can be a repetitive and time-consuming task for Salesforce Admins, but it is also perhaps the most common one that every Salesforce professional learns from day one. It seems only fair to have OpenAI Operator start with this task before moving on to more complex ones to see if it can complete it.

When provided with a complete prompt – including all the details about the field, as well as any optional information you would like it to input – Operator can do so without issue. It can also accept in-flight instructions before proceeding with the initial task. In this example, it was asked to limit the permissions during field creation. Even though it had not yet reached that page, it did not get confused; it knew to confirm but also act on the instructions as soon as it received the user confirmation.

Without all the details in the prompt or subsequent instructions, the agent still successfully created the fields as instructed, began limiting the permissions until the user took control, and correctly chose the layout to add them to once again. Since the information was not provided, it stopped and asked the user which type of field should be chosen, realising the information was missing. The agent did not abandon the initial task, even when it was asked to close an unrelated in-app guidance prompt.

This time, it encountered challenges with selecting the field type but succeeded in the end, adding and naming a page layout section, as well as dragging fields into the desired layout section. While not an actual challenge, but something it will learn over time considering it was able to use this method, it tried to limit the permissions by unchecking each checkbox one by one, instead of using the checkbox at the top, as a Salesforce Administrator would most likely do nowadays, since the option is available. This time, it was not told to do it any other way and simply chose the more time-consuming route.

Additionally, while it completed the mandatory fields for the field creation, it chose not to ask about or complete the Description or Help Text. This was expected, considering it was not told to do so in the prompt to begin with.

Operator was under the impression that it had succeeded in moving the fields in the desired section and naming it accordingly; however, that wasn’t exactly the case. There is only one field within the dedicated new section, while the other one remains where it was automatically added during its creation. The agent was confused by the placeholder text for the section name and appended the new section name to the existing text. This happened a couple of times, until it was specifically instructed in the prompt or ad hoc instructions to remove the placeholder text first.

If the need to drag and drop is removed from the equation, though, the agent breezes through the field creation, as well as making edits to the respective page layout!

Edit Dynamic Forms

Dynamic Forms is a newer Salesforce functionality, and while Page Layouts have been around for the longest time, Salesforce Administrators have to consider the new capabilities this feature brings to the table to enhance the user experience. Similar to what happened with the Page Layout above, OpenAI Operator was under the impression that all fields were positioned correctly, when in fact not all of them had been moved where requested.

Once again, removing the need to drag and drop and asking for something else instead worked better. While there was a need to provide more instructions and correct it due to the component selection, Operator successfully added a filter to one of the fields and was also able to test to ensure the change worked as intended. Not only that, but although the placeholder text for the field in the filter seemed to confuse it at first, it managed to figure it out on its own and select the correct field.

Validation Rules and Formula

Creating multiple validation rules across key Salesforce objects to support or enforce certain business processes is surely part of every admin’s day-to-day work. Creating a validation rule is where OpenAI Operator did its best work, though: faster, complete, and tested. You will notice that, unlike when it was asked to create fields, the agent proactively completed the Description even though it was not asked to.

After the validation rule task went so smoothly, it’s only normal that we would also test its skills in creating formula fields. While we knew from the field creation task that it may have a challenge selecting the field type (which did not happen this time), an unexpected occurred when Operator asked for help as it was trying to access the Lead object by clicking on the API Name instead of the hyperlink after searching for it in Object Manager.

Unlike the action it took with the validation rule, it did not proactively check the formula syntax. You will notice that its first attempt did not use ISPICKVAL() or TEXT() for the picklist field value and prompted an error upon save. Operator needed guidance to identify and check the error, went back and forth adjusting the formula even right before saving it, but in the end, it created and also tested the new field.

Once again, it did not ask about the Description or Help Text, and while it was asked before to amend permissions and layouts during field creation, it didn’t ask about these pages either. This confirms that, as always, the prompt it initially receives or the subsequent instructions should be specific in order for it to perform the task in more detail and not skip through pages.

Create Test Records and Report

When customizing in a sandbox, Salesforce Admins usually create a few records they need to test the changes, using various mechanisms. Since Operator has just created a formula field on a Lead, let’s have it create a few test Lead records. You might have already noticed above that it asked before making updates to records, and this scenario was no different. After asking the first time and being told to continue without asking for the others, it proceeded to finish creating ten test Leads.

Operator needed a bit of help when filtering the records in the report, but it also failed to correctly save the report, even after attempting to recreate it. However, it did ask the user for confirmation when selecting the report type to ensure it is the correct one, which it was.

By changing the initial prompt to a more detailed one and reinforcing the use of the “Save & Run” button, it was able to save the report successfully. Additionally, even though it did not initially add the correct filters, it could be instructed to correct them and also save the report from the run page.

Create a Salesforce Flow

With Process Builder and Workflow Rules well on their way to being deprecated, Salesforce Admins have to turn to Salesforce Flow to support their organization’s automation needs. 

For its very first attempt at creating declarative automation, OpenAI Operator chose to navigate to Process Builder. However, after being told to choose Flow the first time, it navigated directly to Salesforce Flow in all subsequent attempts – it learned. 

When prompted to automatically set the Opportunity Close Date to the current date, Operator chose to use the Stage for the entry criteria instead of IsClosed. While it could have opted to use $Flow.CurrentDate to update the record, it chose to create a formula resource and make use of TODAY() after even attempting to write the date in. 

It didn’t face any challenges with selecting the right circle this time; however, it didn’t consider the “Optimize the Flow for:” section until it was told to go back and change it. Again, it didn’t ask about adding a Description, but it could successfully use the Debug functionality prior to activating the Flow. If this information is added in the prompt from the beginning, or even provided ad hoc, it correctly chooses the right Flow type, the entry criteria of your choice (if you have a preference), and can easily add a Description when saving the Flow. 

Note that during every task, you can view the agent’s thought process as it performs the action in real time by clicking on the down arrow on its reply bubble. This information is also retained if you choose to review it later.

Since Operator didn’t ask about optimizing the Flow for either Fast Field Updates or Actions and Related Records, what if we asked it to create a different automation with the same entry criteria but a different action? It didn’t use the existing Flow but chose to create a new one, correctly optimized for Actions and Related Records.

A Salesforce Admin would probably justify having the two separate Flows: one being triggered before the record is committed to the database, as it only had to update the triggering record, and the other optimized for actions and related records because it creates a task. Operator regarded the request for justification as a mistake, even though it was not, and offered to combine the flows instead of providing a reason for the choice or re-evaluating the context of the automations.

Additionally, in the previous example, when updating a field on the triggering record, it ultimately succeeded in determining the desired value by itself. However, when it came to using the Create Records element and needing to use the Opportunity Owner’s Id, it mistakenly mapped it to the resulting Task Id from the Create Record element, despite being certain it would be assigned to the Opportunity Owner. However, it rectified the mapping once provided with additional instructions. This once again showcases the importance of not only knowing what to ask the agent for but also spotting when and if something needs to be corrected.

READ MORE: How Many Flows Should You Have Per Object?

Summary

As you have seen in the examples above, when provided with complete and detailed prompts, along with any necessary instructions, OpenAI Operator can complete most tasks correctly and as requested by the user. Not only that, but it can fail fast, change direction, and act on instructions even during task execution, without the user necessarily having to take control.

While Operator is not perfect and should be closely monitored when performing the tasks – in case it asks for confirmation, makes mistakes, asks additional questions, or gives up control to the user because it gets stuck on a certain step – the potential exists and is sure to increase as it learns from the user interactions and additional instructions provided.

Have you already tested out OpenAI Operator for any Salesforce tasks? Let us know in the comments below!

The Author

Andreea Doroftei

Andreea is a Salesforce Technical Instructor at Salesforce Ben. She is an 18x certified Salesforce Professional with a passion for User Experience and Automation. 

Comments:

    JS
    February 07, 2025 7:17 pm
    I don't get this. It's faster to do the things you asked for (Except for repetitive items, like adding test records) directly then typing out the detailed prompts required to get Operator to do it.
    Fabrice Cathala
    February 12, 2025 3:23 pm
    "While Operator is not perfect and should be closely monitored when performing the tasks" I think that, right now, this is the downfall of this technology. When implementing Salesforce, typically, we are not working on a POC but on a real-life revenue-impacting system. There is no "play time" authorised when touching "production"... Although Operator has the potential to greatly improve efficiency (hence costs to get new custom features), I believe that too much automation equals too many risks... I would recommend not to jump on the bandwagon, and forgeting about the risks. Wait for maturity instead...

Leave a Reply