
Bitte wählen Sie die Bereiche, die Sie exportieren möchten:

Schulung Salesforce-Entwicklung: Apex, Lightning Web Components und Flows
Trigger, LWC, Flow Builder, DevOps und Agentforce-Erweiterung
Schulungsformen
Inhouse-/Firmenschulung
- 3 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Beschreibung
Die zentrale Architektur-Entscheidung in jedem Salesforce-Projekt lautet daher: Deklarativ (Flows) oder programmatisch (Apex/LWC)? Die Antwort ist nicht entweder-oder, sondern die richtige Kombination. Flows für Standardautomatisierung, Apex für komplexe Geschäftslogik und Integrationen, LWC für interaktive UI-Erfahrungen - und alle drei zusammen als Agentforce-Actions, die KI-Agenten aufrufen können.
Dieses Seminar deckt den aktuellen Entwicklungs-Stack ab. Wer Salesforce administrieren (nicht entwickeln) möchte, findet „Admin Grundlagen" (S3311, 2T) und „Admin Aufbau" (S3747, 4T). Wer Agentforce-Agenten konfigurieren möchte, findet „Salesforce Agentforce" (NEU, 2T). Wer LLM-APIs unabhängig von Salesforce nutzen möchte, findet „OpenAI, Anthropic & Gemini API" (S6723, 3T).
Tauchen Sie tiefer ein mit einer weiteren Salesforce Schulung aus unserem Seminarangebot.
Schulungsziel
Jede teilnehmende Person verlässt das Seminar mit einer vollständigen Feature-Lösung (Apex Backend + LWC UI + Flow Automatisierung + Agentforce-Action), einer konfigurierten DevOps-Umgebung (VS Code, CLI, Scratch Org), getesteten Apex-Klassen (90 %+ Coverage) und dem Verständnis, wann deklarativ und wann programmatisch die richtige Wahl ist.
Details
Inhalt
- Ziele und Erwartungen der Teilnehmenden
- Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
- Tag 1: Apex - Serverseitige Geschäftslogik
- 1. Salesforce-Entwicklungsumgebung und DevOps
- Salesforce CLI und VS Code: Salesforce Extension Pack installieren, Projekt erstellen, mit einer Org verbinden. CLI-Kommandos: sf org create scratch, sf project deploy start, sf apex run.
- Scratch Orgs: Kurzlebige Entwicklungsumgebungen (max. 30 Tage) - sauber, reproduzierbar, isoliert. Scratch Org Definition File: Welche Features, welche Lizenzen? Vorteil gegenüber Sandboxes: jeder Entwickler hat seine eigene, saubere Org.
- Source Tracking und Deployment: Source-of-Truth ist das lokale Projekt (nicht die Org). Pull/Push zwischen VS Code und Scratch Org. Deployment in Sandboxes und Production: Change Sets (Legacy) vs. Metadata API vs. Salesforce CLI (modern).
- Projektstruktur: force-app/main/default/ - classes (Apex), lwc (Lightning Web Components), flows (Flow-Definitionen), objects (Custom Objects), permissionsets. Package-basierte Entwicklung für größere Teams.
- Praxis-Übung: Salesforce CLI installieren, Projekt erstellen, Scratch Org anlegen, ein Custom Object per Metadata deployen, Änderungen pullen und pushen.
- 2. Apex Grundlagen: Syntax, Datentypen und SOQL
- Apex im Kontext: Stark typisierte, objektorientierte Sprache auf der Salesforce-Plattform - syntaktisch ähnlich zu Java, aber mit Plattform-spezifischen Besonderheiten (Governor Limits, Bulkification, DML-Operationen).
- Datentypen und Variablen: Primitive (String, Integer, Decimal, Boolean, Date, DateTime), Collections (List, Set, Map), sObjects (Account, Contact, Custom Objects). Null-Handling.
- SOQL und SOSL: SOQL (Structured Object Query Language) für Datenbankabfragen: SELECT Name, Email FROM Contact WHERE AccountId = :accId. Beziehungsabfragen (Parent-to-Child, Child-to-Parent). SOSL (Salesforce Object Search Language) für Volltextsuche über mehrere Objekte.
- DML-Operationen: insert, update, upsert, delete, undelete. Database-Methoden (Database.insert mit allOrNone-Parameter für partielle Erfolge). DML in Bulk: Listen statt Einzelsätze.
- Governor Limits verstehen: 100 SOQL-Queries pro Transaktion, 150 DML-Statements, 10.000 Datensätze pro DML. Warum diese Limits existieren (Multi-Tenant-Architektur) und wie man innerhalb der Limits arbeitet.
- Praxis-Übung: Apex-Klasse schreiben, die alle Contacts eines Accounts abfragt (SOQL), einen Calculated Field berechnet und das Ergebnis speichert (DML). In der Developer Console und via CLI ausführen.
- 3. Trigger und Trigger-Framework
- Trigger-Konzept: Code, der automatisch bei DML-Events ausgeführt wird - before insert, before update, after insert, after update, before delete, after delete, after undelete. Before-Trigger (Daten ändern bevor sie gespeichert werden) vs. After-Trigger (Daten lesen nachdem sie gespeichert wurden, Folgeaktionen auslösen).
- Trigger-Anatomie: trigger AccountTrigger on Account (before insert, before update) { ... }. Trigger-Context-Variablen: Trigger.new, Trigger.old, Trigger.newMap, Trigger.oldMap, Trigger.isInsert, Trigger.isBefore.
- Bulkification: Der häufigste Fehler: SOQL/DML innerhalb einer for-Schleife. Richtig: Daten sammeln (Set/Map), eine SOQL-Query außerhalb der Schleife, eine DML-Operation am Ende. „Collect, Query, Process, DML."
- Trigger-Handler-Pattern: Trigger selbst enthält keine Logik - delegiert an eine Handler-Klasse. Vorteile: Testbarkeit, Wiederverwendbarkeit, Übersichtlichkeit. Beispiel: AccountTriggerHandler.handleBeforeInsert(Trigger.new).
- Praxis-Übung: Trigger schreiben: „Wenn eine Opportunity auf 'Closed Won' gesetzt wird -> Account-Feld 'Letzter Auftragseingang' aktualisieren und einen Task für den Account Owner erstellen." Bulkification sicherstellen (200 Opportunities gleichzeitig).
- 4. Fortgeschrittenes Apex: Async, Callouts und Testing
- Asynchrones Apex: Future Methods (@future - einfach, aber begrenzt), Queueable Apex (flexibler, verkettbar), Batch Apex (für Massendaten: Millionen Datensätze verarbeiten), Scheduled Apex (zeitgesteuerte Jobs - täglich um 6 Uhr). Wann welcher Typ?
- Callouts (HTTP-Requests): REST-APIs aufrufen - HttpRequest, HttpResponse, Named Credentials (sichere Credential-Verwaltung). JSON-Parsing mit JSON.deserialize und Wrapper-Klassen. Callouts in Triggern: nicht direkt erlaubt -> Future oder Queueable nutzen.
- Apex Testing: Jede Apex-Klasse braucht mindestens 75 % Code Coverage für Production Deployment. @isTest-Klassen, Test.startTest()/stopTest() für Governor-Limits-Reset, Test-Daten erstellen (nicht auf Produktionsdaten zugreifen), System.assert-Methoden.
- Invocable Methods (@InvocableMethod): Apex-Methoden, die von Flows und Agentforce-Actions aufgerufen werden können - die Brücke zwischen deklarativ und programmatisch. Input/Output-Variablen definieren, Bulk-fähig gestalten.
- Praxis-Übung: Invocable Method schreiben (externe API aufrufen, Ergebnis am Case speichern), Test-Klasse mit 90 % Coverage erstellen, Batch-Job für Massen-Update schreiben.
- Tag 2: Lightning Web Components - UI-Entwicklung
- 5. LWC-Architektur: Web Standards statt proprietäres Framework
- Warum LWC? Visualforce (2006) und Aura (2014) sind Legacy. LWC (2019) nutzt Web Standards: HTML Templates, JavaScript ES Modules, CSS Custom Properties, Shadow DOM. Entwickler bringen ihre JS-Kenntnisse mit, kein proprietäres Framework lernen.
- LWC vs. Aura vs. Visualforce: LWC (modern, performant, Standards-basiert, empfohlen), Aura (Legacy, aber noch in Bestandssystemen), Visualforce (Legacy, nur für Spezialfälle wie PDF-Generierung). Migration: Aura->LWC ist möglich, Visualforce->LWC ist ein Neuschreiben.
- Anatomie einer LWC-Komponente: myComponent.html (Template), myComponent.js (Controller), myComponent.css (Styles), myComponent.js-meta.xml (Konfiguration: wo einbettbar, welche Properties). Alles in einem Ordner unter force-app/main/default/lwc/.
- Datenbindung und Reaktivität: Reactive Properties (UI aktualisiert sich automatisch bei Änderung), @track (implizit seit LWC), @api (öffentliche Properties, von außen setzbar), Getter für berechnete Werte.
- Praxis-Übung: Erste LWC-Komponente erstellen - eine Karte, die Account-Details anzeigt (Name, Branche, Umsatz). Per @api recordId den aktuellen Datensatz empfangen. In der Scratch Org auf einer Record Page platzieren.
- 6. LWC: Daten, Events und Salesforce-Integration
- Lightning Data Service (LDS): Datenzugriff ohne Apex - @wire(getRecord) und @wire(getFieldValue) lesen Datensätze direkt. updateRecord() und createRecord() für DML. LDS nutzt den Client-Cache: schneller und effizienter als Apex-Calls. Standard-CRUD-Operationen ohne eine Zeile Apex.
- Wire Service und Apex: @wire(apexMethode) ruft Apex-Methoden reaktiv auf - Ergebnis wird automatisch aktualisiert. Imperativ: apexMethode() als Promise für on-demand-Aufrufe (Button-Clicks). Wann Wire, wann imperativ?
- Events und Komponentenkommunikation: Custom Events (Kind->Eltern), Lightning Message Service (Kommunikation zwischen unverbundenen Komponenten), Platform Events (Server->Client, Echtzeit).
- SLDS und UI-Komponenten: Salesforce Lightning Design System - fertige CSS-Klassen und UI-Komponenten (lightning-card, lightning-datatable, lightning-record-form, lightning-button). Konsistentes Look-and-Feel ohne eigenes CSS.
- lightning-record-form, -edit-form, -view-form: Formulare für Datensatz-Anzeige und -Bearbeitung mit minimalem Code - Felder definieren, Layout automatisch. Für schnelle CRUD-Oberflächen reichen 10 Zeilen HTML.
- Praxis-Übung: LWC-Komponente erweitern: eine Datatable mit allen Opportunities eines Accounts (@wire + Apex), Filter-Input (Suchfeld), Custom Event bei Klick auf eine Opportunity, Navigation zur Opportunity-Detail-Seite.
- 7. LWC: Fortgeschrittene Patterns und Deployment
- Custom Flow Components: LWC-Komponenten, die in Screen Flows eingebettet werden - benutzerdefinierte UI-Schritte, die über Standard-Flow-Elemente hinausgehen. Input/Output-Properties für Datenübergabe zwischen Flow und LWC.
- Lightning App Builder Integration: LWC auf Home Pages, Record Pages, App Pages platzieren. Design Properties (Admin konfiguriert die Komponente per Drag-and-Drop: „Zeige die letzten 5 oder 10 Opportunities?"). Visibility Filters (Komponente nur anzeigen, wenn Bedingung erfüllt).
- LWC in Communities/Experience Cloud: Komponenten für Kundenportale und Partner-Portale - andere Kontexte (Guest User, Community User), Sicherheitsaspekte.
- Testing: Jest-Tests für LWC - DOM-Assertions, Event-Simulation, Mock-Wire-Adapter. @salesforce/sfdx-lwc-jest installieren und konfigurieren. Mindestens Happy-Path-Tests für jede Komponente.
- Praxis-Übung: Custom Flow Component bauen (Produktauswahl mit Bildern und Beschreibung - reicher als ein Standard-Picklist), in einen Screen Flow einbetten, auf einer Record Page platzieren.
- Tag 3: Flows, Integration und Agentforce-Development
- 8. Flow Builder für Entwickler: Deklarativ + Programmatisch
- Flows als First-Class-Automatisierung: Salesforce empfiehlt: „Erst Flow, dann Apex." Flows decken 80 % aller Automatisierungsanforderungen ohne Code ab. Apex für die restlichen 20 % - komplexe Logik, Callouts, Performance-kritische Operationen.
- Flow-Typen im Überblick: Record-Triggered (Before-Save: Fast Field Updates, After-Save: Folgeaktionen), Screen Flows (Benutzerinteraktion), Autolaunched (ohne UI, per API/Apex aufrufbar), Scheduled (zeitgesteuert), Platform-Event-Triggered (Echtzeit-Events).
- Flows mit Apex erweitern: Invocable Actions - der Flow ruft eine Apex-Methode auf, wenn die deklarativen Möglichkeiten nicht reichen. Beispiel: Komplexe Berechnung, externer API-Call, PDF-Generierung. Input/Output-Variablen definieren, Fehlerbehandlung.
- Custom Flow Components (LWC): Wenn Standard-Screen-Elemente nicht reichen - eigene LWC-Komponenten als Flow-Schritte. Beispiel: Drag-and-Drop-Priorisierung, interaktive Karte, Rich-Text-Editor.
- Flow Best Practices: Bulkification (Entry Conditions statt Decision-Loops), Error Handling (Fault Paths, Custom Error Messages), Performance (keine verschachtelten Subflows ohne Notwendigkeit), Dokumentation (Descriptions, Labels).
- Praxis-Übung: Record-Triggered Flow mit Invocable Apex Action (Case erstellt -> Apex prüft Kundenvertrag in externer API -> Flow setzt Priorität und SLA basierend auf Ergebnis). Flow testen und debuggen.
- 9. APIs und Integration: Salesforce mit der Außenwelt verbinden
- REST API: Standard-Endpoints für CRUD auf Salesforce-Objekten. Custom REST-Endpoints mit @RestResource - eigene API für externe Systeme, die Salesforce-Daten lesen/schreiben. Request/Response-Format (JSON), Authentifizierung (OAuth 2.0, Connected Apps).
- Platform Events: Echtzeit-Messaging innerhalb und außerhalb von Salesforce - Publish/Subscribe-Pattern. Salesforce publiziert ein Event (Case eskaliert) -> externes System reagiert (Slack-Nachricht, PagerDuty-Alert). Flows und Apex können Events publizieren und abonnieren.
- Change Data Capture (CDC): Automatische Events bei Datenänderungen - ein externer Service wird in Echtzeit informiert, wenn sich ein Account, Contact oder Custom Object ändert. Für Synchronisation mit Data Warehouses, ERP-Systemen, Analytics-Plattformen.
- Named Credentials und External Services: Sichere Verwaltung von API-Credentials (kein Passwort im Code). External Services: OpenAPI-Spezifikation importieren -> Salesforce generiert automatisch Apex-Klassen und Flow-Actions für die externe API.
- Praxis-Übung: Custom REST-Endpoint erstellen (GET /cases/:id -> Case-Details als JSON), mit Postman aufrufen. Platform Event definieren, per Apex publizieren, per Flow abonnieren.
- 10. Agentforce-Development: Actions für KI-Agenten bauen
- Entwickler-Rolle in Agentforce: Admins konfigurieren Agenten (Topics, Instructions). Entwickler bauen die Actions , die Agenten aufrufen - Apex Invocable Methods, Autolaunched Flows, Prompt Templates, Custom REST-Endpoints.
- Apex-Actions für Agentforce: Eine @InvocableMethod, die der Agent aufruft - z.B. calculateDiscount(opportunityId) -> Agent fragt: „Soll ich den Rabatt für diese Opportunity berechnen?" -> ruft die Methode auf -> gibt das Ergebnis in natürlicher Sprache an den Kunden weiter.
- Flow-Actions für Agentforce: Autolaunched Flows als Agent-Actions - für Standardprozesse, die kein Apex brauchen (Case-Status ändern, E-Mail senden, Datensatz erstellen).
- Prompt Templates: Salesforce Prompt Builder - Templates mit Merge Fields (CRM-Daten), Grounding (Data Cloud), Output-Format (Text, JSON). Prompt Templates als wiederverwendbare KI-Bausteine.
- MCP-Integration (Model Context Protocol): Agentforce unterstützt MCP - externe Tools und Datenquellen als MCP-Server anbinden, die der Agent dynamisch nutzen kann.
- Praxis-Übung: Eine Apex-Action für Agentforce erstellen (Kundenbonität prüfen: Account-Daten lesen, Bestellhistorie berechnen, Scoring zurückgeben). Die Action im Agent Builder als Action registrieren. Agent testen: „Wie ist die Bonität von Kunde X?"
- 11. Praxis-Workshop: „Ein Feature - drei Säulen"
- Phase 1 - Backend mit Apex (30 Min):
- Apex-Klasse mit Geschäftslogik schreiben (Berechnung oder Integration).
- Trigger für automatische Ausführung bei Datenänderung.
- Invocable Method für Flow- und Agentforce-Zugriff.
- Test-Klasse mit 90 %+ Coverage.
- Phase 2 - UI mit LWC (25 Min):
- LWC-Komponente, die die Apex-Methode per @wire aufruft und Ergebnisse anzeigt.
- Interaktive Elemente (Filter, Buttons, Datatable).
- Auf Record Page im App Builder platzieren.
- Phase 3 - Automatisierung mit Flow (20 Min):
- Record-Triggered Flow, der die Invocable Method als Action nutzt.
- Screen Flow mit der LWC als Custom Flow Component.
- Agentforce-Action registrieren.
- Phase 4 - Deployment und Review (15 Min):
- Lösung von Scratch Org in Sandbox deployen (CLI).
- Peer-Review: Code-Qualität, Bulkification, Test Coverage.
- Diskussion: Was deklarativ (Flow), was programmatisch (Apex/LWC)?
Zielgruppe & Vorkenntnisse
- Salesforce-Entwickler: Die den modernen Technologie-Stack (Apex, LWC, Flows) beherrschen und produktionsreife Lösungen bauen möchten.
- Web-Entwickler mit JavaScript-Kenntnissen: Die in die Salesforce-Entwicklung einsteigen - LWC nutzt Standard-HTML/JS, kein proprietäres Framework.
- Salesforce-Administratoren mit Flow-Erfahrung: Die den Übergang zum Entwickler machen und verstehen möchten, wann Flows reichen und wann Apex/LWC nötig ist.
- Architekten und technische Projektleiter: Die Entwicklungsansätze bewerten - Deklarativ (Flows) vs. Programmatisch (Apex/LWC) vs. Agentforce-Actions.
Ihre Schulung
In Präsenz | Online |
|---|---|
| Lernmethode | |
Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC. | Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent. |
| Unterlagen | |
Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. | Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. |
| Arbeitsmaterialien | |
Din A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its | |
| Teilnahmezertifikat | |
Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF. | |
Organisation
In Präsenz | Online | |
|---|---|---|
| Teilnehmendenzahl | ||
min. 1, max. 8 Personen | ||
| Garantierte Durchführung * | ||
Ab 1 Teilnehmenden | ||
| Schulungszeiten | ||
| ||
| Ort der Schulung | ||
GFU SchulungszentrumAm Grauen Stein 27 51105 Köln-Deutz oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden. Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen. | ||
| Räumlichkeiten | ||
Helle und modern ausgestattete Räume mit perfekter Infrastruktur | Bequem aus dem Homeoffice von überall | |
| All-Inclusive | ||
Frühstück, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch | Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu. | |
| Barrierefreiheit | ||
Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei | - | |
Kostenfreie Services
In Präsenz | Online |
|---|---|
|
|
Buchungsmöglichkeiten
Online oder in Präsenz teilnehmen
Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Was bedeutet Offene Schulung und Inhouse Schulung?
Bei einer offenen Schulung stehen Ort und Termin vorab fest. Jeder Interessent kann eine offene Schulung buchen, daher treffen Teilnehmer aus verschiedenen Unternehmen aufeinander.
Inhouse Schulungen können auf Ihren individuellen Schulungsbedarf zugeschnitten werden. Sie bestimmen den Teilnehmerkreis, Termin und Schulungsort.
Ist eine Inhouse Schulung die richtige Wahl?
Bei einer Inhouse Schulung gehen wir auf die individuellen Bedürfnisse Ihres Unternehmens ein und decken den Schulungsbedarf direkt bei Ihnen im Unternehmen ab.
Das spart Zeit und Geld und sorgt für einen schnellen Wissenstransfer Ihrer Mitarbeiter.
Wer kümmert sich um die Technik bei Inhouse Schulungen?
Eine komplette Lernumgebung in der Cloud mit Remote Zugriff ist für uns selbstverständlich. Sie müssen sich um nichts kümmern. Lediglich ein funktionierender PC oder Notebook mit Internetanschluss sollte für jeden Teilnehmer am Schulungstag bereit stehen.
Vorteile einer Inhouse Schulung
- Kompetente Seminarberatung
- Dozenten aus der Praxis
- Auf Ihre Bedürfnisse zugeschnittener individueller Lernstoff
- Sie können den Termin flexibel gestalten, so wie es für Sie am besten passt
- Unsere Inhouse Schulungen können Europaweit durchgeführt werden
- Der Fokus liegt auf Ihrem Schulungsbedarf, somit schonen Sie Ihr Budget
- Wissenslücken Ihrer Mitarbeitet werden schnell geschlossen
GFU Schulungszentrum