Skip to content
TechnicalSFCCSFRA

SFRA Folder Structure Part 3: Exploring the SFCC Scripts

An examination of the Scripts folder in SFRA — how helper scripts, factories, and service integrations handle complex operations so controllers stay clean and testable.

Bhupender Pareek Bhupender Pareek

In the first two parts of this series, we covered the overall SFRA folder structure and took a deep dive into controllers. In Part 3, we turn to the Scripts folder — the engine room that keeps controllers clean and focused.

SFRA scripts folder structure overview

The Role of the Scripts Folder

The Scripts folder is an essential component that fuels the functionality of your storefront. Its purpose is to maintain lightweight controllers by housing the logic that would otherwise clutter them.

Think of controllers as command centres that respond to user interactions. When those command centres grow large and complex, they become harder to read, test, and modify — like trying to add extra floors to a building without a clear plan. The Scripts folder solves this by providing a home for everything that controllers should delegate.

Why Lightweight Controllers Matter

Controllers that are focused on orchestration — receiving a request, calling the right helpers, returning the right response — are dramatically easier to maintain than controllers that also perform complex calculations, external API calls, and data transformations inline.

When business requirements change (and they always do), updating a helper script is a contained, testable change. Updating logic buried in a controller touches more surface area and carries more risk.

Helper Scripts

Helper scripts export functions that supply necessary data and execute logical operations. When you need to display additional product attributes, perform complex pricing calculations, or integrate a third-party service, the right approach is to expand a helper function rather than embed the logic directly in the controller.

Key Subfolders

SFRA scripts subfolders: factories, helpers, hooks, jobs, services

The Scripts folder is divided into five major subfolders:

  • Factories — responsible for creating and returning model objects, providing a consistent way to construct complex data structures
  • Helpers — utility functions used across multiple controllers and scripts
  • Hooks — extension points that allow functionality to be injected into the platform’s standard processing pipeline
  • Jobs — scripts executed by the SFCC job scheduler for batch processing tasks
  • Services — integrations with external systems and APIs, keeping all service communication logic in one place

Summary

The Scripts folder is where the real work happens in an SFRA codebase. Controllers coordinate; scripts execute. Understanding this separation — and consistently enforcing it in your own code — is one of the most practical things you can do to keep an SFCC implementation maintainable as it grows.

In future articles, we will go deeper into each of these subfolders individually and look at specific patterns for factories, hooks, and service integrations.


Have a question or a different take? Drop a comment on Medium — I read every one.

For deeper discussions, architecture questions, or anything you'd rather keep off a public thread, feel free to get in touch directly.

Read on Medium ↗
All writing