Welcome back to The ACCS Edit. Last week, we looked at how the David Nieper team can now change their website just by asking. This time, we're looking at Adobe App Builder, and why it's one of the things that makes Adobe Commerce as a Cloud Service (ACCS) stand out.
What is App Builder?
On ACCS, custom features and integrations are built with App Builder.
It's Adobe's platform for building apps that run alongside a store rather than inside it. App Builder gives brands the flexibility and freedom to add, change and improve functionality, all while Adobe takes care of hosting and security instead of a third party.
Adobe runs the core of every ACCS store and keeps it up to date. So anything a brand needs that doesn't come as standard is built as an app that sits alongside the store. That could be sending orders to a warehouse, pulling stock levels from an ERP, adding a delivery option at checkout or adding a new button in the admin.
It isn't something shoppers see, and it isn't a drag-and-drop tool. Developers build the apps, and App Builder is where they live and run.
How it makes ACCS stand out
For the brands we work with, App Builder means:
No servers to look after. Apps run on Adobe's own cloud, so there's nothing to set up, host or maintain.
Hosted and secured by Adobe. Adobe hosts and secures the cloud the apps run on and keeps it up to date, rather than leaving it to a third-party host.
Quicker to connect. Apps plug straight into Adobe's systems, which makes linking a store to its warehouse, ERP or CRM quicker.
Scales on its own. Apps scale automatically, so they keep up on the busiest days, like Black Friday.
Tested and released on their own schedule. Every App Builder project comes with separate stage and production workspaces, so changes can be tried out safely and go live when they're ready.
In Edit #2, we looked at how Adobe protected ACCS merchants from PHP2Shell before it was made public. App Builder means that protection doesn't stop at the platform: the custom features built on top of it are hosted and secured by Adobe too. Under Adobe's shared responsibility model, each brand's own team still looks after its users and who has access.
An example of how it works
Here's what happens when a customer places an order on a store with a warehouse integration built on App Builder:
A customer places an order. The store sends out a signal to say a new order has come in.
App Builder picks it up. The app that handles orders wakes up on Adobe's cloud.
It sends the order to the warehouse. The app passes the order details straight to the warehouse system, ready to be picked and packed.
Then it switches off again. There's no server sat running in between orders.
Most App Builder apps follow the same pattern. The store sends out a signal when something happens, the right app picks it up, and the app updates the store or passes the information on to other systems. The store can also ask an app a question mid-checkout, such as which delivery options to show.
What else it can do
The same approach works for almost anything a store needs to connect to. On ACCS, App Builder apps can:
Keep stock and prices up to date, straight from the ERP.
Send customer details to the CRM, so every team sees the same data.
Add new options at checkout, like extra delivery or payment methods.
Add new tools to the admin, such as buttons and panels for the team.
For common jobs, like connecting back-office systems or customising the checkout, Adobe provides starter kits that give each project a head start.
That's what makes ACCS stand out for us. We can build exactly what each brand needs and get it live faster, with Adobe looking after the security of where it all runs.
:quality(75))
:quality(75))
:quality(75))
:quality(75))