TL;DR — 10 years of ORGanizer, and a fresh start.
On September 25, 2026, ORGanizer for Salesforce turns ten. To celebrate, I’ve been working on one of its most substantial updates yet: a refreshed website, better management of Salesforce organizations and Quick Links, an improved Quick Console, and new tools such as Access Lens and ORG Health Monitor.
There’s also a lot happening behind the scenes, particularly around encryption, browser permissions, cross-browser compatibility, and security transparency. And I’m already planning company-managed controls that will let organizations disable features that don’t align with their internal policies.
The Salesforce ecosystem has evolved enormously over the past decade, and so have tools like Inspector Reloaded and sfdx-hardis. For a long time, the biggest obstacle to evolving ORGanizer wasn’t a lack of ideas — it was finding the time. AI-assisted development is finally helping me change that.
This release is about more than adding features. It’s about giving a ten-year-old side project the foundations, attention, and momentum it needs for what comes next.
Ten years ago, on September 25, 2016, I published the first version of ORGanizer for Salesforce.
At the time, I was simply trying to solve a problem I had as a Salesforce developer: I was working with multiple organizations, switching between environments, remembering which credentials belonged to which customer, and constantly repeating the same operations.
I thought a small browser extension could make my life easier. I built one, published it, and eventually discovered that quite a few other people had exactly the same problems.
Fast-forward ten years, and ORGanizer has become something much bigger than that original experiment. Thousands of Salesforce professionals use it to manage their daily work, and over the years, it has grown to include tools for developers, administrators, consultants, and just about anyone who spends a significant part of their working day inside Salesforce.
It has also become a rather complicated piece of software to maintain. 🙂
I’ve spent a considerable amount of time over the past months revisiting parts of ORGanizer that had been around for years, reviewing its security model, reconsidering how certain features should work, and building new capabilities that I had wanted to introduce for a long time.
The result is a new release that I’m planning to publish around September 25, 2026, to celebrate ORGanizer’s tenth anniversary.
I want to walk you through what is changing, why I made some of these decisions, and what they mean for the people who use the extension every day.
And since this is ORGanizer, there’s also a fair amount of code, experimentation, and lessons learned behind the scenes.
First, why change something that already works?
One of the things I’ve learned from maintaining ORGanizer for so long is that adding features is relatively easy compared to keeping everything coherent.
You introduce a small utility because someone needs it, then another one, then a configuration option, then a workaround for a Salesforce UI change. Before you know it, a feature that originally consisted of a few lines of JavaScript has grown into something that touches half the extension.
This is particularly true for browser extensions, where you have to deal with different browser engines, changing APIs, security restrictions, Salesforce releases, and the occasional unexpected change to a login page that has worked perfectly for years.
Over time, ORGanizer accumulated a lot of functionality, but not all of it was organized as well as I would have liked. Some features were difficult to discover, certain configuration screens needed attention, and parts of the underlying architecture deserved a proper review.
I also wanted to reconsider the relationship between ORGanizer and security.
Let’s be clear: an extension that can manage credentials, handle authentication flows, and interact with Salesforce sessions is dealing with sensitive information. There’s no point pretending otherwise.
As more people use ORGanizer in professional environments, these considerations become increasingly important. I wanted to make the choices behind the extension more explicit, reduce unnecessary access where possible, and improve the protection available to users who decide to store their credentials.
So rather than concentrating exclusively on adding another collection of features, I decided to work on the foundations too.
That doesn’t mean rewriting everything for the sake of rewriting it. In fact, many of the features that people have been using for years remain familiar. The goal is to make ORGanizer more useful, maintainable, and transparent without asking everyone to relearn their daily workflow.
The ecosystem didn’t stand still while I was busy
Of course, ORGanizer wasn’t the only thing evolving over these ten years.
The Salesforce ecosystem has changed enormously, and so have the tools that help us work with it. What used to be a relatively small collection of browser extensions, scripts, and developer utilities has grown into a much richer landscape of applications built by people who understand the everyday frustrations of working with Salesforce.
Just look at Salesforce Inspector Reloaded. The original Inspector was already an incredibly useful tool, and the community-driven Reloaded project has taken it much further, adding capabilities such as REST API exploration, metadata dependencies, Flow analysis, debug log inspection, and plenty of improvements to data export and import.
Over the years, a few people have described Inspector as a competitor to ORGanizer.
I understand the comparison. There are areas where the two extensions overlap. But I’ve never really looked at it that way.
I think Inspector is a fantastic tool. I’ve used it myself on several occasions, and it’s been genuinely helpful.
My impression has always been that, despite some shared functionality, the two projects started from slightly different needs. Inspector puts a strong emphasis on inspecting and manipulating Salesforce data and metadata, particularly for administrators, developers, and integrators. ORGanizer started with the problem of managing multiple Salesforce accounts and environments, then gradually expanded into the workflows and utilities I wanted to have available throughout my day.
Those audiences certainly overlap, but they aren’t identical. And even when two tools solve the same problem, there can be room for different approaches.
The same broader evolution is visible in projects such as sfdx-hardis. It’s a different kind of solution, built around Salesforce DevOps rather than a browser extension, but it’s a great example of how far community tooling has come: CI/CD pipelines, deployment workflows, organization monitoring, metadata backups, and documentation, with a VS Code interface that makes many of those capabilities accessible without having to live in a terminal.
Seeing projects like these evolve has been inspiring. It has also made me more aware of something I had struggled with for quite a while: ORGanizer needed more than occasional maintenance, and I didn’t always have the time to give it that attention.
For several years, development was often driven by whatever needed fixing most urgently. A Salesforce login page would change, a browser API would behave differently, or a new Salesforce UI would break something that had worked for ages. I’d investigate, fix the problem, publish an update, and move on.
There were still new features along the way, of course. But I had a much longer list of things I wanted to rethink, improve, or build than the time available to work on them.
And this brings me to perhaps the biggest change of all: AI.
We’ve reached a point where AI development tools have become effective enough to make a real difference to how I work on ORGanizer. I can now approach the project almost as if I had a small virtual team supporting me: an IT team helping with implementation, testing, and code reviews; a business team helping me explore ideas and challenge requirements; and even a marketing team helping me think through documentation, communication, and how to explain what I’m building.
They’re not actual employees, obviously. And they still need direction, verification, and someone who takes responsibility for the result. That someone is me.
But the difference in what I can realistically accomplish is substantial.
For the first time in quite a while, I feel I have the means to do more than keep ORGanizer running. I can revisit its foundations, experiment with ideas I’ve had on my list for years, and give the project the attention it deserves.
So this anniversary release isn’t about trying to catch up with Inspector, sfdx-hardis, or anyone else. It’s about finding a sustainable way to keep ORGanizer evolving alongside an ecosystem that has never stopped moving.
A fresh home for ORGanizer
The anniversary is also an opportunity to give ORGanizer’s website a fresh start.
For years, organizer.solutions has been the place where users could find information about the extension, explore its features, check licensing options, and get support.
As the extension evolved, however, it became increasingly difficult to present everything clearly. ORGanizer is no longer just a convenient way to manage Salesforce logins, and explaining what it can do requires more than showing a few screenshots and listing its plugins.
The new portal is intended to provide a more coherent home for the project, giving users a clearer place to discover ORGanizer, understand its capabilities, and find the information they need.
I’m also taking this opportunity to revisit the way the project presents itself visually, while keeping a recognizable connection with the ORGanizer identity that has been around for the past ten years.
I don’t want the website to feel disconnected from the extension. They are two parts of the same project, and they should tell the same story.
Back to the extension: a more organized ORGanizer
Let’s start with the part that existing users will encounter first.
A lot of work has gone into making ORGanizer’s existing functionality easier to navigate and configure.
The extension has always had two important dimensions: managing accounts and helping people work with Salesforce organizations. Although the two are closely related, they are not the same thing.
An account represents a way to log in. An ORG configuration represents how you want a particular Salesforce environment to appear and behave when you’re working with it.
The distinction becomes quite important when you have several accounts for the same organization, or when you’re dealing with sandboxes that are refreshed regularly.
A better way to manage ORG configurations
ORG configurations now have a dedicated management area in the Options page.
You can create configurations manually, edit existing ones, search and sort them, and remove multiple configurations when they are no longer needed. You can also pick from currently connected organizations to create a configuration without having to copy an ORG ID yourself.
The popup remains focused on the organizations you’re actually logged into. You can still make quick changes to a live organization’s label and color there, while the Options page provides the more complete management experience.
There’s also a small but important improvement for people who work with sandboxes: configurations can be matched using My Domain information, helping preserve the relationship between an environment and its settings when a sandbox refresh changes its ORG ID.
It’s the kind of change that probably won’t make anyone particularly excited when reading a release announcement, but can save a surprising amount of frustration in everyday work.
Quick Links, without repeating the same configuration everywhere
Quick Links have also received some attention.
Previously, custom links were primarily associated with individual organizations. That made sense initially, but it could become repetitive when you wanted to use the same link across several environments.
The new configuration model supports both global links, available wherever you use ORGanizer, and links assigned to specific organizations.
All custom Quick Links can be managed from a dedicated Options tab, where you can create, edit, search, and organize them.
Existing per-ORG links are migrated into the new structure, so the intention is to preserve what you’ve already configured rather than make you start from scratch.
The Quick Console gets some much-needed attention
The Quick Console has always been one of the parts of ORGanizer that I personally use the most.
Being able to execute a SOQL query, run anonymous Apex, inspect an object, or access some useful Salesforce information without constantly switching between tools is still one of the main reasons I keep developing this extension.
For this release, I’ve worked on both the experience and some of the tools available inside the console.
The Home tab has been reworked around two simple ideas: showing useful information about your current connection and letting you decide which additional information to retrieve from Salesforce
Saved queries and scripts
I’ve revisited the management of saved SOQL queries and anonymous Apex scripts as well.
V.I.Q. (Very Important Queries) and V.I.S. (Very Important Scripts) now share a more consistent management experience, including the ability to save, edit, duplicate, and organize your snippets.
These are global collections, so a query saved while working in one organization can be available when you move to another.
Of course, that doesn’t mean that the query will necessarily work in every organization. That’s still Salesforce’s problem, not mine. 🙂
What didn’t make it into the new release?
A ten-year anniversary is a good opportunity to introduce new things. It’s also a good time to say goodbye to a few old ones.
Over the years, ORGanizer accumulated features, integrations, and small utilities that made sense when I originally built them. Some were experiments, some addressed very specific needs, and others eventually became redundant as the extension and the browsers themselves evolved.
For this release, I decided not to carry everything forward.
One of the more significant changes is the retirement of Google Drive backup. The integration, its scheduled background job, and the Google authentication machinery behind it have been removed. The old ORGanizer Connector integration has also been retired, including its dedicated tab and backup management interface. The AppExchange application itself is unaffected.
This doesn’t mean you can no longer back up your ORGanizer configuration. The regular export and restore functionality remains available, and it already includes your saved queries and scripts, so the separate Backup V.I.Q. & V.I.S. button is no longer necessary.
I’ve also removed the Salesforce News tab from the popup, along with the old standalone ORG Links page. Quick Links are still very much part of ORGanizer — they now have a dedicated management area in Options — but the @help command has been retired.
On the security side, Timed Password Sessions have been replaced by the new encryption model, which keeps the derived key in memory rather than relying on the previous session mechanism. The extension also no longer requests several permissions associated with older integrations and implementations, including Google OAuth-related permissions and access to googleapis.com.
And then there are a few things you probably won’t miss: the old Chrome Web Store in-app payments library, the blinking changelog icon, and the version-tracking logic that supported it.
I don’t want to pretend that removing features is always a welcome change. If you were one of the people using a retired capability, I understand that its absence may be inconvenient.
But maintaining every experiment and legacy integration indefinitely has a cost, especially in a browser extension that interacts with sensitive information. Each component needs to remain compatible, secure, and tested as Salesforce and browser APIs change.
The goal isn’t to make ORGanizer smaller for the sake of it. It’s to focus my time on the capabilities I can maintain properly and keep improving.
Field History Helper: making an informed decision before enabling tracking
Let’s move to something a little more specific.
One of the questions I often face when working with Salesforce data is whether a field is actually used, and whether enabling or keeping history tracking on it makes sense.
Salesforce gives us the ability to configure field history tracking, but understanding how useful a field is can require additional investigation.
The Field History Helper tries to bring some of that information directly into the Salesforce Setup page.
The earlier implementation relied on a sample of recent records to calculate a couple of indicators. It was useful as an approximation, but it had obvious limitations, especially for larger organizations.
The new implementation uses aggregate queries to retrieve more meaningful information.
It can show field coverage, the number of distinct values, and, where history data is available, the amount of recorded change activity over different periods.
It also gives you visibility into the available tracking slots, helping you understand how much of your object’s tracking allowance is already being used.
The important part is that it doesn’t decide for you.
A field with little recorded activity isn’t necessarily a field you should stop tracking. It might contain information that changes rarely but is extremely important for auditing or compliance.
ORGanizer gives you the data; you decide what to do with it.
The analysis is read-only, and you can refresh it without reloading the entire Setup page.
I’ve also introduced a Field Usage view inside the Quick Console, so you can inspect coverage and distinct values without having to navigate to the Field History Tracking page.
Access Lens: understanding who can access what
This is one of the new features I’m particularly interested in hearing your feedback about.
Salesforce’s permission model is powerful, but investigating access can become quite time-consuming.
You start with a user, look at their profile, inspect their Permission Sets, account for Permission Set Groups, and try to understand which assignment is responsible for a particular permission.
Sometimes you know the user has access to something, but finding out exactly where that access comes from is the difficult part.
Access Lens is designed to make that investigation easier.
You can select an active user and inspect their combined effective permissions across the relevant assignments.
The analysis covers object permissions, field permissions, entity access, and system permissions, with information about the assignments that contribute to each permission.
For example, you might want to understand why a user can edit a particular field, or where a sensitive system permission has been granted.
Instead of manually navigating through several Salesforce Setup pages, you can inspect the combined results and their sources from one interface.
There is also a comparison mode, allowing you to compare two Permission Sets, Profiles, or Permission Set Groups side by side.
Added, removed, unchanged, and differing permissions can be filtered independently, while elevated permissions receive additional visual emphasis.
You can export the results to CSV or JSON if you need to continue the analysis outside ORGanizer.
I see this primarily as an investigation and troubleshooting tool. It isn’t intended to replace a complete identity governance or security auditing platform, and it doesn’t eliminate the need to understand how Salesforce evaluates access in different contexts.
But if it saves you from opening twenty Setup pages to find the Permission Set responsible for a permission, then it’s doing its job.
ORG Health Monitor: a broader view of your Salesforce environment
Another significant addition is the ORG Health Monitor.
This feature comes from a problem that I suspect many administrators and technical leads will recognize: there is a lot of useful operational information in Salesforce, but it is distributed across different Setup screens and APIs.
You can check API consumption in one place, investigate asynchronous jobs in another, look at security settings somewhere else, and then move on to licenses, storage, scheduled jobs, and installed packages.
Each piece of information is useful, but building an overall picture takes time.
The Health Monitor brings several of these areas together in a single dashboard.
The current implementation covers 17 sections organized across multiple tabs, including infrastructure, code quality, automation, operations, licensing, metadata, and security.
You can inspect API and governor limits, storage utilization, Salesforce Health Check results, Apex test coverage, API versions, asynchronous and scheduled jobs, setup changes, automation configuration, and several other indicators.
There are also sections dedicated to installed packages, licenses, security signals, and general ORG hygiene.
The dashboard provides a composite health score based on documented rules and weights. It’s important to understand that this is an ORGanizer assessment, not an official Salesforce certification or an absolute measure of organizational health.
A number can help identify something worth investigating, but it cannot understand every business, architectural, or compliance requirement behind an organization.
I’ve tried to make the underlying methodology visible, so you can understand why a particular result was produced rather than simply being presented with a colored indicator.
Nothing runs until you ask
One of the design choices I care about is that the Health Monitor doesn’t start collecting data as soon as you open it.
You explicitly initiate the analysis.
The individual sections are loaded through a bounded queue, and the dashboard exposes information about the API calls it performs.
Some sections may also be unavailable depending on your Salesforce permissions, enabled features, or the capabilities of the organization.
Rather than silently treating unavailable information as a healthy result, the dashboard is designed to make these limitations visible.
You can export information from the analysis, including a more complete report that can be inspected outside the extension.
And a Live Monitor
There is also a Live Monitor view for observing Salesforce limits over time.
This is useful when you want to see how certain consumption indicators evolve while you’re running an integration, testing a process, or investigating a potential capacity problem.
It isn’t a replacement for a dedicated monitoring service with persistent historical data, scheduled collection, and alerting. The current implementation is still fundamentally a browser-based tool, and its live view is tied to an active monitoring session.
But I think it’s an interesting foundation for what ORGanizer could eventually become.
Keeping up with Salesforce’s changing login experience
Salesforce itself isn’t standing still, either.
The newer email-first login experience introduces an additional step compared with the classic username/password form, including the possibility of selecting an environment before entering the password.
For a tool such as ORGanizer, which has supported quick login for years, that means revisiting assumptions that used to be perfectly reasonable.
The extension now includes support for this newer flow.
Accounts can store a dedicated login email, which may differ from the Salesforce username. When the email-based flow is detected, ORGanizer can offer the appropriate saved accounts, populate the email, and help select the relevant environment.
Where verification is required, the extension leaves that step to the user.
It also avoids making an automatic environment selection when the available information is ambiguous.
The objective is to preserve the convenience of Quick Login without trying to bypass Salesforce’s authentication controls.
You can also add a description to a saved account, making it easier to distinguish similar logins when you’re working with several customers or environments.
Security: the part of this release I don’t want to oversimplify
I want to spend a little more time on security because it’s an area where I think the community deserves a straightforward explanation.
ORGanizer has always provided features that are inherently sensitive, especially credential management and the ability to interact with Salesforce using an existing authenticated session.
Those capabilities are useful, but they also introduce risks.
Over the past months, I’ve been reviewing the extension’s code and architecture, including how credentials are protected, which permissions are requested, how requests are handled, and what happens when data moves between different parts of the extension.
I’ve also been experimenting with AI-assisted security reviews, having different coding agents inspect the same code from different perspectives and then comparing their findings.
This process has been useful, not because AI can magically certify an application as secure, but because it can help identify assumptions and weaknesses worth investigating.
Some findings have led to concrete changes, while others require additional work.
A revised encryption model
One of the most significant changes is the introduction of a new encryption architecture.
The previous implementation relied on older CryptoJS-based mechanisms. The new optional encryption mode uses the Web Crypto API, PBKDF2 with SHA-256 for key derivation, and AES-256-GCM for authenticated encryption.
The derived key is retained in the extension’s background context rather than being persisted to local storage.
There is also a migration path for existing users who have enabled the legacy encryption mode.
However, I want to emphasize something: encryption is optional, and storing credentials in a browser extension still introduces risk.
Encryption at rest helps protect stored data in certain scenarios. It does not make a compromised browser safe, eliminate the risks associated with malicious extensions, or change the fact that credentials must be available in plaintext when an actual login is performed.
The same applies to Salesforce sessions and OAuth tokens. They are sensitive credentials regardless of whether they originate from a password-based login.
If your company has policies that prohibit storing Salesforce credentials in browser extensions, those policies should be respected.
And if you’re working with highly privileged accounts or organizations containing sensitive information, avoiding stored passwords and using approved authentication mechanisms remains an important consideration.
I don’t want to present this release as a magical solution to enterprise security. It’s a meaningful improvement, but security is an ongoing process.
Giving companies more control over which features can be used
This is also why one of the next steps on my roadmap is to introduce company-managed feature controls.
The idea is to give organizations the ability to decide which ORGanizer features their employees are allowed to use and which ones must be disabled to comply with internal security policies. For example, a company might be comfortable allowing developers to use the Quick Console or inspect ORG metadata, while explicitly prohibiting the storage of passwords or the use of certain authentication-related features.
Today, users can configure which features they want to enable, but that’s different from having a policy enforced by the company. The goal is to introduce controls that IT and security administrators can manage centrally, so a restricted feature cannot simply be switched back on by an individual user.
This won’t be part of the anniversary release, and I still need to finalize the implementation and the available policy options. But I believe it’s an important step toward making ORGanizer more suitable for corporate environments, where the question isn’t always whether a tool is useful, but whether it can be used within the organization’s security requirements.
It also means accepting that some companies may want to use only a subset of ORGanizer’s capabilities. And that’s perfectly reasonable: I’d rather give them the option to use the features they’re comfortable with than have the entire extension excluded because of one capability that conflicts with their policies.
Asking for access when it’s needed
Another substantial change is the way ORGanizer handles Salesforce domain permissions.
Historically, the extension requested broad access to Salesforce domains because that was the simplest way to make its features available wherever users needed them.
The new approach moves Salesforce host access into optional permissions.
Instead of asking for access to every Salesforce organization at installation time, ORGanizer requests access to the specific domains associated with the organization you’re working on.
You can also manage these permissions from the Options page.
This doesn’t mean that the extension no longer needs browser permissions. It still requires access to certain browser APIs and its own supporting services, and some Salesforce operations necessarily involve sensitive session information.
But it does mean that the extension can reduce its initial access to Salesforce domains and make those requests more explicit.
The general principle is to request access for a specific purpose rather than assume that every future capability should be available by default.
More visibility into what the extension does
The security work also includes additional controls around network requests, separation between different execution contexts, and a closer review of how untrusted information is handled.
There are still areas I want to improve, and I intend to keep the security documentation updated as the project evolves.
My goal is to provide information that individual users and enterprise security teams can actually use when evaluating ORGanizer, including its permissions, credential-handling model, external services, and known limitations.
Trust shouldn’t depend on someone telling you that an application is secure. It should be supported by documentation, evidence, and a willingness to acknowledge what still needs attention.
One codebase, multiple browsers
Another area that required attention was cross-browser compatibility.
ORGanizer has been available on Chrome, Firefox, and Edge over the years, but keeping the same functionality working across different browsers is not always straightforward…and honestly I was about to remove ORGanizer from the Firefox add-ons portal.
Manifest V3 made some of these differences particularly evident, especially around background execution, browser APIs, and permission handling.
The new codebase includes changes intended to support Chrome and Edge through a service worker, while using Firefox’s supported background execution model.
Several compatibility issues have also been addressed, including differences in cookie stores, script injection, downloads, and extension-specific resource handling.
The objective is to maintain a common codebase rather than developing and maintaining separate versions of ORGanizer for each browser.
Of course, compatibility in the code doesn’t automatically mean that every browser-store submission or review will happen at the same time.
A few words about AI-assisted development
If you’ve been following my experiments over the past year, you probably know that I’ve been spending a lot of time working with AI coding tools.
ORGanizer has become one of my main playgrounds for this.
I’ve used AI coding agents to help investigate bugs, explore implementation alternatives, refactor existing functionality, write tests, and review security-sensitive parts of the code.
The interesting part, at least for me, isn’t simply generating code faster. It’s being able to investigate ideas that would otherwise take considerably more time, especially when working on a project that I maintain alongside my regular job.
That said, using AI doesn’t remove the need to understand what you’re building.
I’ve had plenty of situations where generated code looked perfectly reasonable until I tested it against a real Salesforce organization, tried it in another browser, or discovered that it broke an existing workflow.
And the security reviews have been an especially useful reminder that an AI-generated assessment is not the same thing as independent verification.
I’ve been trying to use these tools to improve the development process while remaining responsible for the final result.
This release contains a lot of that experimentation, and I expect the process to continue evolving.
What about licensing and the free version?
ORGanizer started as a free extension, and its free functionality remains an important part of the project.
Over time, I introduced paid licensing to help support its development and the costs associated with maintaining the service.
I know that licensing is not everyone’s favorite topic, especially when discussing a tool that was originally created as a personal side project.
But keeping a browser extension alive for ten years involves more than writing JavaScript.
There are hosting costs, support requests, changes to Salesforce and browser APIs, store reviews, licensing infrastructure, and the not-so-small matter of finding time to work on all of it.
The objective is to keep ORGanizer accessible while making its continued development sustainable.
The new release doesn’t change that underlying intention. I’ll continue working on the balance between useful free functionality, paid capabilities, and ways to support the project.
And, as always, I’d rather be transparent about why these options exist than pretend that maintaining software indefinitely has no cost.
Ten years later, what comes next?
When I published ORGanizer in 2016, I certainly wasn’t thinking about what it might look like ten years later.
I was trying to make my own Salesforce work a little easier.
The extension has changed a lot since then, and so has the Salesforce ecosystem. The tools we use today, the way we build software, and the expectations around security and user experience are very different from what they were a decade ago.
Some of the changes in this release are immediately visible, such as Access Lens and the Health Monitor.
Others are less exciting to demonstrate but equally important for the long-term health of the project.
I don’t expect every new feature to be useful to every user, and I certainly don’t expect everyone to agree with every design decision I’ve made.
That’s fine.
One of the things I’ve always appreciated about the Salesforce community is its willingness to share feedback, point out problems, and suggest improvements based on real work rather than hypothetical use cases.
Many of ORGanizer’s features exist because someone took the time to explain a problem they were facing, sometimes with a surprisingly detailed description of what they thought the solution should look like.
So if you try the new release, please let me know what works, what doesn’t, and what you think could be improved.
The anniversary release is planned for around September 25, 2026. As usual, its availability may depend on the review and publication process of the different browser stores.
You can find more information at organizer.solutions, and I’ll keep sharing updates as the new version becomes available.
Finally, I want to thank everyone who has used ORGanizer over the years, recommended it to a colleague, reported a bug, suggested a feature, purchased a license, or simply sent me a message to say that it made their Salesforce work a little easier.
Ten years is a long time for a side project.
And knowing that something I originally built for myself has become part of other people’s daily work is still one of the most rewarding parts of maintaining it.
Thank you, Salesforce Ohana.
See you in the next release.
