Keep Your Agentforce Dev Org Alive and Kicking : [email protected] (Bob Buzzard)

Keep Your Agentforce Dev Org Alive and Kicking
by: [email protected] (Bob Buzzard)
blow post content copied from  Bob Buzzard Blog
click here to view original post



### Summary of the Content At the TrailblazerDX '25 event, Salesforce announced new Developer Editions featuring Agentforce and Data Cloud. This is significant because many users had been requesting it since Salesforce launched generative AI capabilities in April 2024. Previously, users faced limitations with temporary access periods for Trailhead specials and Partner SDOs, leading to repetitive manual processes whenever a new organization (org) was created. The new Developer Editions have specific usage timelines: the legacy (non-Agentforce) edition lasts for 180 days, while the version with generative AI features expires in just 45 days if not used. Although Salesforce states that unused orgs may be terminated after 45 days, there's a risk if users don't log in regularly. To manage these constraints, the author suggests using **GitHub Actions** to automate the renewal process for these Developer Editions. GitHub Actions allow users to set up workflows using YAML files, which can automate tasks such as logging in and renewing the org access. ### Key Steps for Automation: 1. **Setup Developer Org**: Sign up for a new Agentforce Developer Org on Salesforce and connect it to the Salesforce CLI. 2. **Create GitHub Repository**: Set up a public repository on GitHub to utilize GitHub Actions. 3. **Add Environment Secret**: Store the Sfdx Auth URL in a secret in the repository settings to keep it secure. 4. **Create YAML Action File**: Define a workflow YAML file that includes commands for renewing the org access. 5. **Run the Action**: You can manually trigger the workflow or set it to run automatically at specified intervals. ### Additional Context This automation is especially useful for developers who frequently use Salesforce but might forget to log in due to their workload. By setting up GitHub Actions, the renewal process becomes seamless, reducing the risk of losing access to the Developer Editions. ### Relevant Hashtags for SEO #Salesforce #DeveloperEdition #GitHubActions #Automation #GenerativeAI #TrailblazerDX #DevOps #CloudComputing #SalesforceCLI #ProgrammingTips



Image generated by OpenAI GPT4o in response to a prompt by Bob Buzzard

Introduction

One of the major announcements at TrailblazerDX '25 was the availability of Salesforce Developer Editions with Agentforce and Data Cloud. This is something that just about everyone has been asking for since the first generative AI features went GA in April 2024. Everything else that wasn't associated with a paid contract expired - Trailhead specials after 5 days and Partner SDOs couldn't be taken past 90 days, and even getting that far required raising a case to extend it past the default 30 days. The icing on the cake was the metadata support wasn't fantastic, which meant manually recreating features after spinning up a new org, which gets a bit samey after the fifth time.

Developer Editions don't live forever though - if you don't use them you lose them. After 180 days for the non-Agentforce variant (now known as legacy) and an evanescent 45 days if you want the generative AI features. Although to be fair, the signup page states that Salesforce "may" terminate orgs that are unused for 45 days rather than "will", but if you've put a lot of effort in you don't want to take any risks.

45 days sounds like a long time and it's easy to assume you'll manage to remember a login every 6 weeks or so, but my experience is that it's easy to get distracted and miss a slot. Machines are much better at remembering to do things on a schedule, so this is one task that I prefer to hand off - in this case to a Github Action.

Access Dev Org Action

Github Actions allows automation of software workflows through YAML (YAML Ain't Markup Language) files. Typically I'd use actions for continuous integration tasks on a project - automated build and test every night, for example - but I can also use it for something simpler. In this case, running a Salesforce CLI command against my dev org. If you set up your environment and secret name as I have, you'll be able to use my YAML file exactly as is.

Setup Dev Org

The first thing to do is get your new dev org and setup CLI access. Sign up for a new Agentforce dev org at : 

https://www.salesforce.com/form/developer-signup/?d=pb

Then connect it to the Salesforce CLI using the command:

> sf org login web -o AFDevOrg

Login with your username/password and approve the oauth access.

Execute the following CLI command:

> sf org display -o AFDevOrg --json --verbose

and copy the Sfdx Auth Url output value

Now you have this value, you can move on to the Github steps.

Create Your Repository

In order to use Github actions on a free account, your repository will need to be public. This doesn't mean that your Dev Org becomes public property, as you'll be storing the Sfdx Auth Url in an environment secret that only you as the repository owner can see:



Create Your Environment and Secret

Once you've created your repository, you need an environment to store your secret - click the Settings tab on the top right and choose the Environments option on the left hand menu:

Click the New environment on the resulting page, then name your environment and click the Configure environment button:


On the resulting page, scroll down to the Environment secrets section and click the Add environment secret button:

Name your secret, paste the Sfdx Auth Url value in the Value textbox and click the Add secret button.


Create and Execute Your Action

The final setup step is to create the YAML file for your action. This needs to live in the .github/workflows repository subfolder and can be called anything you like - I've gone for:

.github/workflows/renew.yaml

Once the file is present, clicking on the Actions tab will show the name of the action in the All workflows list on the left hand side - Renew Agentforce Dev Org Lease in this case.


Click on the name to see the run history and other options. There are no runs yet, but I've defined a workflow_dispatch event trigger so that I can run it on demand - in my experience this is well worth adding.

Start a run by clicking the Run workflow dropdown and the resulting Run workflow button:

I find that either the page doesn't refresh or I can't wait for that to happen, so I click the Actions tab again to see the In progress run:


Clicking on the run name gives me a little more detail:

And clicking the card shows me workflow steps - I've waited until they all completed successfully, so my run is green!

Switching out to my dev org, upon checking my user record I can see that there's an entry matching the action execution, although obviously it comes from a Github IP address in the US:

And that's it. As well as the workflow_dispatch event trigger, I've also specified a cron trigger so that it executes at 20:30 every Monday - more than every 45 days, but that gives me some wiggle room if my job starts failing and I don't get around to fixing it quickly.

More Information






March 22, 2025 at 11:13PM
Click here for more details...

=============================
The original post is available in Bob Buzzard Blog by [email protected] (Bob Buzzard)
this post has been published as it is through automation. Automation script brings all the top bloggers post under a single umbrella.
The purpose of this blog, Follow the top Salesforce bloggers and collect all blogs in a single place through automation.
============================

Salesforce