Redukcja długu technicznego w instancji Salesforce

Dług techniczny to nie abstrakcja z prezentacji CIO. Według McKinsey około 40% budżetów IT pochłania utrzymanie legacy, a Stripe szacuje, że deweloperzy poświęcają ~42% czasu na obsługę złego kodu i jego konsekwencji. W ekosystemie Salesforce rok 2026 bywa wręcz nazywany „rokiem długu technicznego” — bo firmy, które chcą wdrażać Agentforce i funkcje AI, odbijają się od bałaganu we własnych danych i automatyzacjach.

Skąd bierze się dług techniczny?

W orgu Salesforce dług przybiera dwie główne formy. Dług automatyzacji: Workflow Rules i Process Buildery (koniec wsparcia: 31 grudnia 2025 — nadal działają, ale bez poprawek błędów), nakładające się Flow na tym samym obiekcie, triggery odpalane w nieprzewidywalnej kolejności. Dług konfiguracji: setki nieużywanych pól custom, martwe obiekty, przestarzałe layouty i rozrost profili nieodzwierciedlający realnych ról.

Osobna kategoria to hard-coded ID — identyfikatory rekordów wpisane na sztywno we Flow i Apex różnią się między sandboxem a produkcją, więc automatyzacja pada po deployu. Alternatywy istnieją od lat: API/Developer Name, Custom Metadata Types, Custom Labels.

Dług zżera też twarde limity platformy: maksymalnie 800 pól custom na obiekt, 10 GB file storage w Enterprise Edition, dzienny limit API (~1 mln + 1 000 na użytkownika). Każde martwe pole i każda zbędna integracja przybliża org do ściany.

Audyt instancji

Ważna zmiana: Salesforce Optimizer jest wycofywany — orgi utworzone po sierpniu 2025 już go nie mają, a Winter/Spring ‘26 usuwa go z pozostałych instancji. Zalecany następca to darmowy, open-source’owy Org Check (Salesforce Labs, AppExchange). Pozostały arsenał:

• Health Check (Setup) — procentowy benchmark bezpieczeństwa względem standardu Salesforce
• Salesforce Well-Architected — framework oceny architektury: Trusted / Easy / Adaptable, z antywzorcami do odhaczenia
• Narzędzia third-party: Elements.cloud (analiza populacji pól, dependency analysis), Gearset (mapowanie zależności, „ghost code”), Salto (wyszukiwanie hardcoded wartości)

Przy audycie metadanych nieoceniona jest Salesforce CLI:

sf org list metadata --metadata-type CustomField --target-org prod
sf org list limits --target-org prod
sf data query --query "SELECT MetadataComponentName, RefMetadataComponentName
  FROM MetadataComponentDependency" --use-tooling-api

Ta ostatnia komenda (Dependency API) odpowiada na kluczowe pytanie każdego sprzątania: czy tego pola/Flow ktokolwiek jeszcze używa?

Plan naprawczy

Sprawdzona kolejność: pola → automatyzacje → kod → uprawnienia → dokumentacja.

1. Inwentaryzacja i wycena — każdą pozycję długu wpisz do backlogu z szacunkiem kosztu utrzymania i ryzyka usunięcia.
2. Priorytetyzacja — najpierw to, co blokuje (migracja Workflow Rules/Process Builderów do Flow narzędziem Migrate to Flow; w jednym z opisywanych projektów ~100 Process Builderów skonsolidowano do niecałych 20 Flow), potem to, co kosztuje (nieużywane pola, storage), na końcu kosmetyka.
3. Refaktoryzacja iteracyjna — sprzątanie w sprintach, obok normalnego developmentu, nie jako osobny „projekt porządkowy”, który nigdy nie dostanie budżetu.
4. Governance — konsolidacja profili do permission sets, standardy nazewnictwa, CI/CD i cykliczne przeglądy, żeby dług nie odrósł.

Dług techniczny nie znika od ignorowania — rośnie na procent składany. Każdy release Salesforce’a, każda nowa integracja i każdy nowy admin dokładają odsetki.

Podsumowanie

Sprzątanie orga nie jest efektowne, ale ma dziś konkretny biznesowy powód: bez czystych danych, przewidywalnych automatyzacji i udokumentowanej konfiguracji nie ma mowy o sensownym wdrożeniu agentów AI. Dobra wiadomość: audyt pierwszego rzutu (Org Check + Dependency API + przegląd limitów) to kwestia dni, nie miesięcy — i zwykle sam finansuje resztę programu, pokazując, ile org naprawdę kosztuje.

Źródła: Salesforce Admins — Optimizer Is Sunsetting, Meet Org Check, Salesforce Architects — Well-Architected, Keynode — Workflow Rules & Process Builder Retirement, Salesforce Admins — Avoid Hard-Coding, Gearset — Managing Salesforce Technical Debt, CAST — Coding in the Red (2025)