Salesforce Sandbox: typy środowisk i kiedy które używać

Sandbox to izolowana kopia organizacji Salesforce używana do development, testów i szkoleń – bez ryzyka dla danych i procesów produkcyjnych. Każdy sandbox zawiera kopię metadanych (obiekty, pola, code, konfiguracja) z Twojego orga produkcyjnego. Różnią się tym, czy i ile danych produkcyjnych kopiują, ile miejsca oferują i jak często można je odświeżać. Wybór złego typu sandboxa to albo zbyt mały storage na potrzeby projektu, albo niepotrzebnie drogi sandbox z danymi produkcyjnymi tam gdzie wystarczy sam kod. Poniżej kompletna mapa czterech typów i strategia ich doboru.

Cztery typy sandbox: co zawierają i jak się różnią

Salesforce oferuje cztery typy środowisk sandbox. Poza nimi istnieją Scratch Orgs – osobna kategoria (tymczasowe, source-driven orgi dla DX development, nie sandbox sensu stricto), opisana niżej.

Developer Sandbox to punkt startowy dla każdego developera i admina. Kopiuje wszystkie metadane z produkcji – obiekty, pola, kod Apex, Flow, konfigurację uprawnień – ale nie kopiuje żadnych rekordów danych. Pojemność: 200 MB. Refresh: raz na dobę. W ramach licencji Enterprise Edition każda organizacja otrzymuje 25 Developer sandboxów bez dodatkowych opłat (flosum.com). To środowisko dla indywidualnego dewelopera lub admina pracującego nad nową funkcjonalnością, który nie potrzebuje danych do testów – generuje własne dane testowe lub używa Test Data Factory.

Developer Pro Sandbox to Developer Sandbox z większym storage: 1 GB zamiast 200 MB. Nie kopiuje danych produkcyjnych – tak samo jak Developer. Refresh: raz na dobę. Różnica w praktyce: Developer Pro mieści większe codebazy, więcej zarządzanych pakietów AppExchange, i pozwala załadować większe zestawy danych testowych. Używasz go gdy 200 MB Developer Sandboxa jest za mało, ale nie potrzebujesz danych produkcyjnych (arrify.com).

Partial Copy Sandbox kopiuje metadane plus podzbiór danych produkcyjnych – zdefiniowany przez Sandbox Template. Template to lista obiektów i opcjonalnie filtrów, które decydujesz co skopiować. Limit danych: 5 GB i do 10 000 rekordów per obiekt (sfdcdevelopers.com). Refresh: raz na 5 dni. Enterprise Edition zawiera 1 Partial Copy Sandbox. Ten typ jest właściwy dla UAT (User Acceptance Testing), testów integracyjnych i szkoleń, gdzie testerzy muszą pracować z realistycznymi danymi, ale pełna kopia produkcji jest zbędna.

Full Copy Sandbox to wierna kopia środowiska produkcyjnego: wszystkie metadane i wszystkie dane. Storage: taki jak produkcja. Refresh: raz na 29 dni. To najdroższe i najwolniejsze w odświeżaniu środowisko – refresh Full Sandbox w złożonych organizacjach może trwać wiele godzin lub dni. Używasz go do testów wydajnościowych, pełnych testów regresyjnych przed dużymi wdrożeniami, szkoleń na rzeczywistych danych produkcyjnych. Enterprise Edition zawiera 1 Full Copy Sandbox (flosum.com).

Refresh: co to znaczy i jak planować cykl

Refresh sandboxa to operacja, która nadpisuje jego zawartość aktualnym stanem metadanych (i danych jeśli typ sandboxa je kopiuje) z produkcji. Po refresh wszystkie zmiany wprowadzone w sandboxie od ostatniego refresh są kasowane – to celowy mechanizm resetowania środowiska do stanu „baseline”.

Minimalny odstęp między refreshami (apexhours.com, sfdcdevelopers.com): Developer i Developer Pro – 1 dzień, Partial Copy – 5 dni, Full Copy – 29 dni. To minimalny czas, nie harmonogram – możesz odświeżać rzadziej. W praktyce Full Copy refreshujesz nie częściej niż raz na sprint lub release cycle, bo każdy refresh kasuje środowisko UAT, które ktoś właśnie konfigurował do testów.

Przy refreshu sandboxa usernames są modyfikowane przez dodanie sufiksu (np. user@company.com staje się user@company.com.uat lub user@company.com.dev01). To zabezpieczenie przed przypadkowym logowaniem do sandboxa zamiast produkcji i przed mailingiem w testach do prawdziwych klientów. Automatyzacje wysyłające emaile w sandboxie trafiają na adresy zmodyfikowane – nie do prawdziwych odbiorców.

Sandbox Templates (dostępne dla Partial Copy i Full Copy): definiujesz które obiekty i ile rekordów chcesz skopiować. Dla Partial Copy to kluczowe narzędzie – możesz skopiować 10 000 Account, 5 000 Contact i odpowiadające im Opportunity bez wszystkich gigabajtów historycznych danych. Przy projektowaniu template’u pamiętaj o relacjach: kopiując obiekty dziecko Salesforce automatycznie dodaje wymagane obiekty-rodzice, żeby zachować integralność referencyjną.

Scratch Orgs: czym różnią się od sandboxów

Scratch Org to nie sandbox – to tymczasowe, w pełni konfigurowalne środowisko Salesforce tworzone przez Salesforce DX (SFDX). Żyje od 1 do 30 dni (konfigurowalne), po tym czasie jest kasowane. Nie jest kopią produkcji – tworzysz je od zera definiując features i settings w pliku scratch-def.json.

Scratch Orgs są zaprojektowane dla flow developerskiego opartego na source control: kod żyje w repozytorium Git, Scratch Org to jednorazowe środowisko do pracy nad konkretną funkcją lub bugfixem. Gdy skończysz, zmiany wracają do repo i Scratch Org możesz usunąć. W projektach z wieloma developerami pracującymi równolegle, Scratch Orgs eliminują problem jednego wspólnego sandboxa, w którym wszyscy sobie przeszkadzają.

Scratch Orgs wymagają aktywacji Dev Hub w produkcyjnym orgu i są dostępne od licencji Enterprise. Liczba jednocześnie aktywnych Scratch Orgs jest ograniczona licencją (domyślnie Enterprise: 40 aktywnych, 200 dziennie tworzonych).

Strategia środowisk: jak dopasować sandbox do etapu projektu

Typowa strategia środowisk w projekcie Salesforce to pipeline kilku środowisk, każde z innym celem:

Developer Sandbox (lub Scratch Org): indywidualny developer, bez danych produkcyjnych. Wiele równoległych środowisk dla różnych developerów lub user stories. Codzienny (lub częstszy) cykl zmian i deploymentu do dalszych środowisk.

Developer Pro lub dodatkowy Developer Sandbox: integration sandbox, gdzie zmiany z wielu Developer Sandboxów są łączone i testowane razem przed przejściem do UAT. Ten krok eliminuje konflikty konfiguracyjne odkrywane dopiero na Partial Copy.

Partial Copy: UAT i testy integracyjne z realistycznymi danymi. Tutaj biznes testuje funkcjonalność przed go-live. Refresh co 5 dni – wystarczająco rzadko, żeby UAT miał stabilne dane przez cały sprint, wystarczająco często by nie odstawał od produkcji.

Full Copy: finalna weryfikacja przed deploymentem, testy wydajnościowe, szkolenia użytkowników na danych produkcyjnych. Refresh co 29 dni – raz per major release cycle. Kosztowny i wolny w odświeżaniu, więc używany oszczędnie.

Preview Sandboxes i testowanie nowych release’ów Salesforce to osobny temat – opisywaliśmy jak korzystać z preview orgs przed Summer ’26. Kwestie kontroli metadanych i ryzyk związanych z niekontrolowanymi zmianami konfiguracji pomiędzy środowiskami poruszamy w artykule o metadanych jako ukrytej luce kontroli.

Sandbox to nie tylko miejsce do „testowania zmian przed wdrożeniem” – to infrastruktura, od której zależy jakość i bezpieczeństwo każdego projektu Salesforce. Im wcześniej zaplanujesz strategię środowisk i dobierzesz typy sandboxów do faktycznych potrzeb projektów, tym mniej niespodzianek na etapie UAT i produkcji. Jak wygląda Twoja obecna strategia środowisk i co w niej nie działa?