08 JanWarum haben Salesforce Record-Ids eine Länge von 15 und 18 Zeichen?

Vielleicht seid  Ihr auch schon einmal darüber gestolpert, dass Salesforce Datensätze mal 15 Zeichen lang sind, mal 18. Und hier spreche ich vom gleichen Datensatz, beispielsweise einem Account. Direkt im Link oder in einem Export von einem Report werden 15 Zeichen ausgegeben, nutzt man hingegen den DataLoader sind es 18. Was steckt also dahinter?

Salesforce-15

Der Grund weshalb ich diesen Post schreibe ist, dass ich Zeuge wurde wie ein neuer Admin eine Große Anzahl der vorhandenen 100.000 Account Daten unbrauchbar gemacht hatte indem ihm der Unterschied nicht klar war. Spätestens jetzt habe ich Eure Aufmerksamkeit! (Wir konnten die Daten übrigens retten, es gab ein Backup).

Was steckt also dahinter?

Die 15-stellige ID ist case sensitive, d.h. es ist ein Unterschied, ob eine ID 001i000000032b oder 001i000000032B lautet.
Das Problem entsteht in externen Programmen in denen Salesforce Daten verwendet werden. Excel beispielsweise unterscheidet nicht zwischen Groß- und Kleinbuchstaben, d.h. in einem VLOOKUP (SVERWEIS auf deutsch) sind beide Datensätze die gleichen! Und jetzt wisst Ihr auch schon, dass das sehr häßlich werden kann.

Aus diesem Grund gibt es weitere 3 Stellen, die von Salesforce am Ende hinzugefügt werden wenn Ihr die Daten exportiert. In meinem Beispiel wäre das dann beispielsweise: 001i000000032b43x und 001i000000032Bj4s. Das kann dann auch Excel nicht mehr verwechseln.

Ein gern genommener Anfängerfehler ist, Daten über einen Report zu exportieren und dann in Excel zu verarbeiten.
Das mag zwar bequem erscheinen, ist aber ein totales No-Go. Nutzt für externe Verarbeitung IMMER 18-stellige IDs, am einfachsten geht das über einen DataLoader (Original von Salesforce, Jitterbit DataLoader, dataloader.io oder andere).

Kann ich die 3 zusätzlichen Stellen auch selbst hinzufügen?

In Salesforce selbst sind die IDs 15-stellig gespeichert, das erspart Speicherplatz. Die 3 zusätzlichen Stellen werden bei Bedarf berechnet. Salesforce hat zu diesem Zweck die Formel CASESAFEID(Id) eingeführt. Falls Ihr im Netz auch über komplexe Algorithmen stolpert mit denen Ihr das berechnen könnt, so solltet Ihr wissen, dass die Funktion CASESAFEID(Id) erst in Spring’12 eingeführt wurde, vorher musste man sich mit einer sehr, sehr langen Formel helfen, die seitdem obsolet ist.

Und denkt immer daran: Wenn Ihr Daten in einem externen System verarbeitet, macht vorher ein Backup!

Wie geht Ihr mit den IDs um? Wir freuen uns über Rückmeldungen.

 

11 AugSalesforce 2-Faktor Authentifizierung abschalten – Gewusst wie und wann

Es ist mir wieder passiert: Vor kurzem habe ich meinen Arbeitgeber gewechselt und damit habe ich keinen Zugriff mehr auf meine alte Handynummer und Email-Adresse. Zudem nervt es mich sowieso immer wenn ich mich in reinen Developer-Editionen authentifizieren muss. In diesen Umgebungen hab ich nichts zu verheimlichen, da reicht mir auch eine reine Username und Passwort-Abfrage. Reichlich genervt habe ich die Funktion recherchiert wie man das umgehen kann, hier mein Blogpost dazu:

Gewusst wie

Die Funktion die 2-Faktor-Authentifizierung zu umgehen ist mit guter Absicht etwas im Administrationsmenü versteckt. Ausschalten kann man sie nicht, wohl aber umgehen!

Das Profil bietet die Möglichkeit eine sog. “Login IP Range” einzutragen. Alle Logins die von innerhalb dieses IP Bereiches kommen werden dann ohne weitere Authentifizierungen durchgeroutet, Ihr könnt Euch beim Benutzen von externen Tools zudem die Eingabe des Security Tokens sparen.

Seid Euch bitte bewusst was Ihr hier tut, das hat in einer Produktions-Umgebung meiner Meinung nach nichts verloren. Das ist etwas für Developer-Orgs, nicht mal für Sandboxen.

Login IP Range

 

Gewusst Wann

Eine Möglichkeit die 2-Faktor-Authentifizierung für alle Profile abzuschalten gibt es nicht, sollte es auch nicht geben.

Denn in einer Produktivumgebung werdet Ihr eventuell den umgekehrten Weg gehen wollen:

Hier könnt Ihr die Funktion so nutzen wie sie gedacht ist, nämlich die User gänzlich auszusperren wenn sie nicht innerhalb des IP Bereiches auf die Salesforce-Umgebung zugreifen. Unter anderem ist das für den Einsatz mit VPN gedacht. Hier geht der User über eine VPN-Verbindung ins Netz und hat damit einen festgelegten IP-Bereich.

 

Ich jedenfalls lasse alle Produktiv-Umgebungen unberührt, füge aber in jede Test und Demo-Umgebung seit ein paar Tagen den Bereich von 0.0.0.0 bis 255.255.255.255 – und bin damit auf der sicheren Seite, denn das sind alle IP Adressen, die es weltweit gibt.

 

22 FebSalesforce Freigaberegeln mit APEX

In einem vergangenen Blogpost habe ich zusammengestellt wie man sich in Salesforce die Freigaberegeln definieren kann und habe darauf viele Rückfragen bezüglich APEX bekommen, daher will ich diesem Thema mal hier näher auf den Grund gehen:

Wie funktionieren die Freigaben im Detail – und wie kann man auf die Regeln per APEX zugreifen bzw. diese erstellen?

Das Prinzip ist so einfach wie genial. Um das zu verstehen müssen wir einen kurzen (sehr kurzen!) Ausflug in die Datenbank von Salesforce machen:

Für jedes Objekt für das die Unternehmensweiten Standardeinstellungen NICHT “öffentlicher Lese-/Schreibzugriff” ist, wird eine weiteres Objekt angelegt in dem die Freigaben abgelegt werden. Über die Admin-Bedienoberfläche ist das aber nicht sichtbar. Um darauf zuzugreifen bedient man sich Admin-Tool (z.B. Eclipse, Develpper Konsole, SoqlXplorer etc.) und findet dort das entsprechende Objekt.

Ich habe für Euch die Account-Sicherheitseinstellungen auf privat gesetzt und EINE einzige Freigaberegel erstellt und Euch mit dem SoqlXplorer einen Screenshot gemacht:

AccountSharing

 

Was dann in der Datenbank abgelegt wird ist nicht etwa die Regel selbst, sondern es wird für jeden (!) Account für den eine Freigaberegel erstellt wurde diese in die Sharing-Tabelle eingetragen. In diesem Beispiel wurde also aus einer Regel 12 Einträge.

Das ist auch der Grund weshalb man immer die Meldung bekommt, dass die Regeln “berechnet” werden und das etwas dauern kann nach dem Speichern. Denn Salesforce übersetzt die von Euch erstellten Freigaberegeln auf die Accounts und trägt diese dann in die Tabelle ein. Bei riesigen Datenmengen und entsprechend vielen Usern kann das schon mal richtig viel werden und entsprechend lange dauern.

So, und wie greift man jetzt auf die Tabelle per APEX zu? Ganz einfach: Ihr habt die Chance selbst dort Einträge vorzunehmen bzw. diese auch wieder zu löschen. In der Praxis sieht das dann so aus, dass man (bleiben wir beim Beispiel Account) bei jedem Speichern/Erstellen/Löschen einen Trigger startet, der die Sharing-Regeln in der Tabelle überarbeitet bzw. einträgt.

Ihr legt dort fest welcher User oder welche Gruppe (Vorsicht, das sind keine Chatter-Gruppen, sondern öffentliche Gruppen!) welchen Zugriff auf den Datensatz bekommt.

Mein Tip war und bleibt: Man kommt fast immer mit den Standard-Regeln aus. Erst wenn diese zu 100% ausgenutzt worden sind und Ihr Freigaben braucht, die man einfach nicht anders machen kann, solltet Ihr die APEX-Regeln nutzen.

Was ist Eure Best-Practice?

02 DecSalesforce Integration für Arme

Das Thema wie Daten nach Salesforce hineinkommen und wieder exportiert werden können ist ein Thema, das jeden (aber auch wirklich jeden) vor dem Kauf brennend interessiert, daher möchte ich diesem Dauerbrenner einen Blogpost widmen.

Um es vorwegzunehmen. In meinen 10 Jahren Berufserfahrung war es noch nie so leicht Daten zu laden oder zu entladen wie heute. Die Tools sind einfach klasse geworden.

Daten exportieren

Dafür gibt es eine Funktion im Setup, die es Euch erlaubt alle (!) Daten per Knopfdruck und in Form von csv (Comma Separated Files) zu exportieren. Das beinhaltet auch die Dateien (Powerpoint, Excel etc.), die Ihr im Laufe der Zeit hochgeladen habt. Und ja, Ihr erhaltet auch die Information wie die Daten und Dateien zueinander gehören mit exportiert.

Ich empfehle Euch nachdrücklich die Erinnerungsmail zu nutzen, die Ihr wöchentlich (bei Professional Edition monatlich) erhalten könnt um Eure Daten lokal als Backup zu speichern. Man weiss ja nie, ob mal jemand aus Versehen alte Daten gelöscht hat. Ihr habt aktuell kein Backup bei Euch lokal gespeichert? Los geht!

Daten laden

Wenige Daten könnte Ihr bequem mit Bordmitteln laden – mit dem sogenannten Wizard – der im Setup eingebaut ist (Datenverwaltung -> Datenimport-Assistent). Allein dieses Tool hätte einen eigenen Post verdient, weil es seit der Überarbeitung im letzten Release deutlich hübscher und besser bedienbar geworden ist.

Probiert den Datenimport-Assistenten einfach mal selbst aus, wenn Ihr beispielsweise Accounts laden möchtet.

Und hier mein ultimativer TIP: Speichert Eure Excel Sheets mit OPEN OFFICE als csv-Dateien ab. Microsoft Excel eignet sich nicht zum Arbeiten mit csv-Dateien (das macht statt Kommas Semikolons – weshalb, das muss uns Microsoft noch erklären).

Sobald die Aufgabe etwas kniffliger wird, werdet Ihr mit dem Assistenten an Grenzen kommen. Vor allem dann, wenn Ihr die selbe Aufgabe mehrfach machen wollt, wenn ihr beispielsweise einen Fehler gemacht hattet und die Ursprungsdatei anpassen wollt oder mehr Daten laden wollt etc. werdet Ihr für ein etwas schlaueres Tool dankbar sein.

Für diesen Fall gibt es eine grosse Anzahl an KOSTENLOSEN Tools, die Ihr nutzen könnt.

Den Salesforce DataLoader gibt es als Bordmittel, dataloader.io, den Jitterbit Data Loader, Skyvva und viele mehr könnt ihr ebenfalls nutzen. Sie alle nutzen die Salesforce APIs und unterstützen Euch dabei Eurer Aufgabe Herr zu werden.

Ich persönlich arbeite inzwischen nur noch mit Jitterbit und dataloader.io und zwar aus folgenden Gründen:

Bei beiden Tools kann ich mehrere Logins hinterlegen (z.B. Testumgebung, Produktionsumgebung) und sämtliche Vorgänge (Laden von Daten, Exportieren etc.) speichern. Gerade wenn ich regelmässig Vorgänge durchführen muss, dann ist das super weil es mir Zeit erspart.

Mein Favorit ist seit Neuestem dataloader.io

Letzte Woche hatte ich einen Kunden am Telefon, der mit dem Assistenten an Grenzen gekommen war und dem ich dataloader.io empfohlen habe – und er war begeistert, so wie ich.

Seit dem letzten Release von dataloader.io lassen sich Laden- und Entlade-Vorgänge mit regelmässiger Abfolge automatisieren – und das kostenlos! Ihr legt beispielsweise fest, dass jeden Tag um 7:00 Uhr ein CSV-Sheet die Umsatzdaten Eurer Accounts aktualisiert – und das geschieht nach der einmaligen Konfiguration von allein.

Ihr könnt als Quelle FTP, Dropbox oder box.com angeben. Den Ausspruch “Integration für Arme” habe ich von meinem Kunden gerne an dieser Stelle übernommen.

Ihr habt somit die Möglichkeit Daten aus Bestandssystemen, Buchungssystemen, was auch immer nach Salesforce automatisch einmal am Tag hochzuladen. Oder alternativ Daten einmal täglich nach FTP, Dropbox oder box.com zu exportieren und von dort weiterzuverarbeiten.

Überlegt selbst welche Möglichkeiten Euch damit zur Verfügung stehen! Und das kostenlos! Bisher haben alle Tool-Hersteller Geld für Prozess-Automatisierungen genommen, dataloader.io hat das jetzt durchbrochen. Und macht damit natürlich Werbung für deren richtig, richtig schicke Integrations-Plattform Mulesoft, die Euch mit dem CloudHub noch ganz andere Möglichkeiten bietet (Ein Blick auf deren Portfolio lohnt sich!)

Natürlich bekommt Ihr keine Garantie für den Betrieb von dataloader.io und es ersetzt kein hochwertiges Integrationswerkzeug. Aber für eine Integration von unkritischen Daten auf dennoch sicherem Weg ist es unschlagbar gut.

Probiert es aus, Ihr werdet begeistert sein wie leicht sich Daten laden, mappen und exportieren lassen.

Wieso ist das bei Salesforce so einfach?

Ganz einfach, weil Salesforce konsequent auf offene Standards setzt und APIs für den Zugriff auf das System zur Verfügung stellt. Die anderen Hersteller verfolgen da den Weg die User in ihrer eigenen Welt einzusperren. Es ist oft ein Drama auf die Daten bei anderen Systemen zuzugreifen, von einfachen Wegen die Daten zu verarbeiten ganz zu schweigen. Für Ihr Integrations- bzw. Migrations-Projekt benötigt Ihr jetzt “nur noch” Zugriff auf die anderen Systeme, dann geht’s los.

Für Migrations-Projekte macht Euch schon heute an die Analyse darüber wie Ihr die Daten aus Euren Altsystem entladen bekommt. Diese Frage werdet Ihr Euch künftig nicht mehr stellen brauchen. Sie wurde in nur wenigen Zeilen hier beantwortet.

Welche Tools nutzt Ihr, was sind Eure Erfahrungen, welche Use Cases könnt Ihr Euch vorstellen mit den Möglichkeiten von dataloader.io?

02 DecSalesforce Video – Firmenprofil & Trust.com

Gerne wird vergessen die Grundeinstellungen einer Salesforce-Umgebung richtig zu wählen, was Euch dann später Ärger bereiten kann.

In diesem Video diskutieren Tobias und ich ausgiebig die Salesforce Firmeneinstellungen

  • Firmeninformationen
  • Geschäftsjahr
  • Geschäftzeiten
  • Feiertage
  • Spracheinstellungen
  • Trust.com

Aus unserer Sicht ein Muss für jeden Admin diese Themen zu verstehen, damit die Umgebung sauber aufgesetzt ist.

Erst danach sollte mit dem Bauen von Feldern, Layouts und Prozessen beginnen.

Viel Spass beim Zuschauen. Wir freuen uns auf Euer Feedback!

 

11 SepCloudBlogger Video: Neues Salesforce Setup

Im Juni hatten wir unseren CloudBlogger Youtube-Kanal eröffnet und in unserer ersten Episode vorgestellt, worauf Administratoren achten sollten, wenn sie das erste Mal in einer neuen Salesforce Umgebung unterwegs sind. Episode 2 hatten wir bereits vor einigen Tage nach der Umstellung auf das Summer ’13 Release aufgenommen, aber erst jetzt veröffentlicht.

Episode 2 handelt von folgenden Punkten:

  • Ausblenden der Randleiste zur Bildschirmoptimierung
  • Neue Platzierung von Setup / Meine Einstellungen
  • Aufbau der neuen Setup-Struktur

 

19 AugJeder sieht nur was er soll – Freigaberegeln entmystifiziert

So ziemlich jeder Kunde hat den Wunsch in seiner Software genau zu regeln wer von den Mitarbeitern welche Daten sehen darf.

Die Möglichkeiten die Freigaberegeln von Datensätzen zu definieren sind sehr vielfältig und haben mich dazu bewogen hier mal zusammenfassen zu schildern welche Wege Euch zur Verfügung stehen wenn Ihr die Freigaben verwalten wollt.

Der Einstieg: Unternehmensweite Standardeinstellungen

Hinter dem im deutschen nicht so richtig prickelnden Begriff steckt eine absolut essentielle Funktionalität. Nicht umsonst wird darauf in der Administrator-Prüfung sehr ausführlich eingegangen.

Recht oder Zugriffsreche in Salesforce zu vergeben funktioniert immer nach dem generellen Muster:

Es gibt eine Standardeinstellung und man kann Benutzern weitere Rechte hinzugeben. Daher ist es wichtig die Grundeinstellungen richtig zu setzen. Wenn die ganze Firma Account-Daten lesen und schreiben sollen darf, dann wäre die Standardeinstellung entsprechend – und es gebe keinen weiteren Grund mehr für zusätzliche Freigaberegeln.

Ihr habt grundsätzlich 3 Möglichkeiten (es gibt wenige Ausnahmen auf die ich hier nicht eingehen möchte):

  • Privat – Nur der Datensatzinhaber hat Zugriff auf den Datensatz
  • Öffentlicher Lesezugriff – Die ganze Firma hat lesende Rechte auf den Datensatz, nur der Datensatzinhaber hat das Recht ihn zu editieren
  • Öffentlicher Lese-/Schreibzugriff – Alle in der Firma haben Zugriff auf den Datensatz und dürfen ihn bearbeiten

Wenn ihr einen der ersten beiden Einstellungen für Eure Objekte ausgewählt habt, dann gibt es noch weitere Orte an denen Ihr den Benutzern freigaben erteilen könnt – und darum soll sich dieses Blog drehen.

Um alle Punkte im Detail mit Praxisbeispielen zu erörtern würde sich eher ein Buch anbieten als ein Blog, gedacht ist das Blog an dieser Stelle zum Einstieg und zum Überblick:

1. Freigaberegeln – der Klassiker

Am bekanntesten dürften die Freigaberegeln sein. Im Setup kann man unter Freigaberegeln die unternehmensweiten Einstellungen vornehmen und auch gleich ausnahmen definieren. Abhängig von jedem (!) Feld auf Eurem Datensatz könnt Ihr Regeln definieren wer zusätzlich die Daten sehen kann.

Ein Klassiker deshalb, weil man in 90% der Fälle damit schon am Ziel ist und die Freigaben für ganze Gruppen, Teams und Rollen aus Eurem Org-Chart geben könnt. Probiert es mal aus.

2. Manuelle Freigaben

Wenn Ihr den Button “Manuelle Freigabe” in Eurem Layout habt und der Benutzer das Recht hat Freigaben zu erteilen, dann könnt Ihr so Euren Benutzern individuell das Recht geben Datensätze Kollegen freizugeben. Es ist halt kein automatisierter Prozess, sondern für alle Sonderfälle gedacht und gemacht bei denen Ihr explizit keine Automatisierung wollt.

3. Account Teams – Auch für Opportunities und Cases

Ebenfalls ein manueller Prozess: Wenn Ihr in größeren Teams arbeitet, dann bietet es sich eventuell an mit Account Teams zu arbeiten. Wenn Ihr einen Kollegen in Euer Account Team aufnehmt, dann gebt ihr ihm Zugriff auf den Account selbst und nach Wunsch auch direkt Zugriff auf die Opportunities und die Cases. Ob Vollzugriff oder nicht: Einstellungssache.

TIP: Wenn Ihr das öfter nutzt, dann definiert Euch bei Eurem User Euer Standard Account Team. So tut Ihr Euch leichter Euer Team hinzuzufügen.

4. Opportunity Teams

Ähnlich wie Account Teams könnt Ihr auf Euren Opportunities Teams definieren mit denen Ihr arbeiten wollt und die Zugriff auf Euren Datensatz bekommen. Ist so ähnlich wie manuelles Sharing, aber mit dem Zusatz, dass Ihr den Kollegen (und Partnern) Rollen geben könnt, die Euch die Zusammenarbeit vereinfacht.

5. Rollenhierarchy – Zugriff auf Opportunities

Recht unbekannt ist, dass man auch im Org-Chart definieren kann wie der Zugriff auf Opportunities ist deren Account-INHABER man selbst ist. Ich selbst empfehle immer die Einstellung so zu setzen, dass man Zugriff auf alle Opportunities. Nur in Ausnahmefällen macht es Sinn anders vorzugehen.

6. Territories – Zugriff auf ein komplettes Gebiet

Zunächst müssen die Territories von Salesforce über ein Ticket aktiviert werden. Wenn Ihr das getan habt und diese nutzt, dann vergesst bitte nicht, dass auf diese genutzt werden können für Freigaben in Eurem Territory: Generell sehr Ihr alle Accounts in Eurem Territory, aber auch der Zugriff auf Kontakte, Opportunities und Cases kann hier geregelt werden.

Der Einsatz von Territories sollte genau abgewogen werden. Wenn Ihr tatsächlich in Teams arbeitet, kann der Einsatz mehr als Sinn machen. Probiert es am Besten mal in einer Development-Umgebung oder Sandbox vorab aus – niemals in Produktion, das es sich aktuell nicht wieder abschalten lässt!

7. APEX Freigaberegeln

Solltet Ihr mit den Freigaberegeln und den anderen Möglichkeiten tatsächlich an Grenzen stossen (was mir selbst noch nicht passiert ist), dann steht Euch der Weg offen über Code nach Eurem wohlgefallen Regeln zu erstellen und Freigaben zu erteilen.

Mein Fazit

Die Einsatzmöglichkeiten von Freigaben sind sehr vielfältig und quasi unlimitiert. Versucht wenn möglich mit den Sandard-Einstellungen auszukommen, die sehr, sehr mächtig sind.

Nutzt die anderen Möglichkeiten nach Bedarf, bedenkt aber bitte auch, dass Ihr als Admins das auch pflegen müsst und dann erteilte Freigaben im Zweifelsfall an neue Kollegen übertragen müsst.

Daher mein Rat (wie bei so vielem): Wägt die Möglichkeiten gut ab und entscheidet Euch dann für wenige der oben genannten Optionen. Ihr wollt ja lange Freude an Eurer Salesforce-Umgebung haben.

Was sind Eure Erfahrungen? Wie geht Ihr vor?

 

 

 

17 JulAdmin Basics: Darum überschreibt man niemals nie einen bestehenden Benutzer

Nachdem ich es in den letzten Tagen zweimal mit dem gleichen Problem bei Kunden zu tun hatte, möchte ich dieses Blog einem totalen Basic widmen, das viel zu wenig Beachtung findet: dem Benutzer.

Jeder Nutzer in Salesforce wird als Benutzer angelegt und bekommt seinen Login-Namen und legt sich selbst ein Passwort fest. Was aber, wenn der Benutzer ausscheidet und ein anderer seine Funktion übernimmt?

Der schnellste – und leider auch schlimmste – Weg ist einfach den vorherigen Benutzer zu überschreiben, die Emailadresse auszutauschen, den Login-Namen zu ändern und das Passwort zurückzusetzen. So einfach kann das gehen, hier nur ein paar der Nachteile die Ihr Euch dabei einhandelt:

Wenn wir und klar machen, dass die Historie des neuen Benutzers dabei übernommen wird, wird vieles klar:

  • Der neue Benutzer hat bereits viele Daten angelegt, letzte Änderungen vorgenommen
  • Der neue Benutzer hat bereits Aktivitäten, die eigentlich gar nicht seine sind
  • Die persönlichen Einstellungen des Benutzers sind bereits gefüllt
  • Die Feldhistorie (wer hat was wann geändert) wird verfälscht
  • Reports können etwas Falsches aussagen, wenn auf diverse Systemfelder reportet wird

Richtig übel wird es aber, wenn Ihr Chatter einsetzt (was ich Euch hiermit nachdrücklich empfehlen möchte, solltet Ihr es noch nicht tun!):

  • Alle alten Posts werden auf den neuen Benutzer übertragen
  • Der neue Benutzer ist in Gruppen eingetragen, für die er eigentlich keinen Zugriff haben sollte
  • Andere Benutzer wundern sich, wieso bei alten Posts ein anderer User steht
  • etc.

Ihr seht, Ihr handelt Euch nur Nachteile ein.

Der richtige Weg ist folgender:

Deaktivert erst den alten Benutzer, denn so bekommt Ihr sofort die Lizenz freigegeben, die Ihr benötigt um den neuen Benutzer anzulegen. Danach legt einen neuen Benutzer an und schenkt ihm ein jungfreuliches Profil. Benennt den alten User eventuell um, beispielsweise von “Sabine Stub” in “X – Sabine Stub”, dann weiss jeder in der Firma, dass die Person nicht mehr aktiv ist.

Danach übertragt die Accounts, Kontakte und offenen Opportunities und Kundenvorgänge mit den eingebauten Admin-Klick-Tools an jemand anderen.

Glaubt mir, das bisschen Arbeit lohnt sich sehr. Es wird Euch viele Rückfragen des neuen Benutzers ersparen und damit Eure und seine Zeit und Frustration sparen.

Welche Erfahrungen habt Ihr mit der Administration von Benutzern gemacht? Über welche Themen sollen wir bloggen? Wir freuen uns auf Euer Feedback.

 

12 JunCloudBlogger jetzt mit Youtube-Kanal

Nachdem Tobias und ich den Gedanken die Salesforce-Administration in kurzen Videos zu erklären schon sehr lange verfolgen, freuen wir uns Euch heute unser erstes CloudBlogger-Video zu präsentieren.

Ihr wollt wissen, was die ersten Schritte in Salesforce sind und wie erfahrene Salesforce Admins eine neue Umgebung aufsetzen? Dann seit Ihr bei uns richtig.

Wir haben uns vorgenommen in weiteren Folgen eine komplette Salesforce-Umgebung mit vielen Prozessen Schritt für Schritt zu entwickeln und aufzubauen und wollen dabei auch auf Eure Fragen eingehen und Tipps und Kniffe von zusammen 5 Jahren intensiver Arbeit mit Salesforce und 10 Salesforce-Zertifizierungen einfließen lassen.

Episode 1 handelt von folgenden Punkten:

  • Zugang zu einer neuen Salesforce-Umgebung
  • Was finde ich wo?
  • Erstellen einer ersten Applikation in Salesforce
  • Austauschen des Firmenlogos

Wir freuen uns auf Euer Feedback. Welche Themen sind für Euch am interessantesten? Was wolltet Ihr schon immer mal wissen?

P.S.: Technischer Hinweis: YouTube verschluckt leider das Bild der ersten ca. 1.30 min – danach gibt’s auch Interessantes zu sehen. Verpasst habt ihr nur die ersten beiden Webseiten www.cloudblogger.de und www.salesforce.de.