CRM + ( 2 x Outlook) = "Tylko jeden może być klientem synchronizacji ….”

Zapewne część osób, które korzystają z dodatku Outlook spotkały się z sytuacją kiedy w momencie synchronizacji danych z CRM pojawiał się komunikat podobny do tego:

You already have Microsoft Dynamics CRM for Outlook installed on another computer. Only one client computer per user can run the automated process that does bulk updates of outlook items with Microsoft Dynamics CRM Data. This client should be the computer that is most often online (such as a desktop computer) or the users primary computer. To change the Synchronizing client, on the CRM Menu, click options, and click the synchronizing tab

lub po polsku

Program Microsoft Dynamics CRM dla programu Outlook jest już zainstalowany na innym komputerze użytkownika. Tylko na jednym komputerze klienckim użytkownika można uruchomić automatyczny proces zbiorczej aktualizacji elementów programu Outlook na podstawie danych programu Microsoft Dynamics CRM. Klientem powinien być komputer, który częściej pracuje w trybie online (na przykład komputer stacjonarny, lub podstawowy komputer użytkownika. Aby zmienić klienta synchronizacji, w menu programu CRM kliknij polecenie Opcje, a następnie kliknij kartę Synchronizacja.

Inaczej może objawiać się takim komunikatem:

image

Co on oznacza ? Dodatek Outlook może pobierać dane z CRM tylko na jednej maszynie – o tym, na której decyduje sam użytkownik poprzez ustawienia dodatku, w zakładce Synchronizacja.

Jednakże mając odpowiedzieć na pytanie: “Jak żyć w takiej sytuacji, kiedy użytkownik korzysta z dwóch Outlooków ?” zacząłem sprawdzać co tak naprawdę jest synchronizowane pomiędzy CRM a Outlook – czego nie może robić dodatek, który nie jest klientem synchronizacji, co się dzieje z danymi kiedy mając dwa Outlooki przełączamy regularnie to, który z nich jest klientem synchronizacji. Dalej opisałem kilka przypadków, które wydają się dla mnie dość cenne :)

Założenie:  Posiadam dwa komputery, które mają zainstalowany Outlook (obsługują dwa różne adresy @) wraz z dodatkiem do CRM, oba skonfigurowane przy pomocy tego samego konta CRM, wskazują na tą samą organizację (nazwijmy te maszyny odpowiednio O1 oraz O2. O1 jest klientem synchronizacji.

  1. Co się dzieje kiedy chcemy śledzić wiadomości email, które otrzymujemy na O1 oraz O2 ?
  2. Co się dzieje kiedy wiadomości email z CRM są wysyłane poprzez dodatek ?
  3. Co się dzieje z terminem kiedy powstał w CRM i chcemy żeby trafił do Outlook ?
  4. Co się dzieje kiedy chcemy śledzić termin, który powstał w Outlook ?

Uwaga: pisząc tylko o działaniu Termin odnoszę się do pozostałych działań, takich jak Zadanie, Rozmowa Telefoniczna (ale bez Email – dlaczego ? zapraszam do lektury).

Ad 1: Co się dzieje kiedy chcemy śledzić wiadomości email, które otrzymujemy na O1 oraz O2 ?

W tym przypadku nie jest istotne, który dodatek Outlook jest klientem synchronizacji, a który nie jest – możemy śledzić wiadomości @ na obu maszynach bez żadnych ograniczeń.

Ad 2: Co się dzieje kiedy wiadomości email z CRM są wysyłane poprzez dodatek ?

Oczywistą oczywistością ;) jest, że aby dodatek mógł wysyłać wiadomości @ musi być zaznaczona odpowiednia opcja w jego ustawieniach:

image

Jeśli to samo zaznaczenie zrobimy w O1 oraz O2 co nam to da ? Oba będą wysyłać emaile! W momencie uruchomienia procesu synchronizacji danych w O2 otrzymamy komunikat widoczny na pierwszym screenie w tym poście, ale jak otworzymy zakładkę Zadanie w tym okienku zobaczymy takie coś:

image

Wniosek: jeśli chodzi o wysyłanie @ nie jest istotne, który Outlook jest klientem synchronizacji.

Ale …. co jeśli O1 i O2 obsługują dwie różne adresy @ ? NIC, a może i DUŻO – to jaki adres @ obsługuje Outlook jest dla dodatku w ogóle nieistotne w przypadku wysyłki @ – z CRM pobierane są wiadomości do wysłania na podstawie pola nadawca (identyfikator użytkownika) – nie jest sprawdzane jaki adres @ jest ustawiony na formularzu użytkownika – może być dowolnym innym adresem przez O1 i O2 nie obsługiwanym jeśli chodzi o pocztę przychodzącą

Ad. 3 Co się dzieje z terminem kiedy powstał w CRM i chcemy żeby trafił do Outlook ?

Tutaj już nie jest tak fajnie jak w przypadku @. Termin ten trafi tylko do tego Outlooka, który jest klientem synchronizacji, w naszym przypadku będzie to O1. A co jeśli następnie zmienimy ustawienia i O2 będzie klientem synchronizacji i wykonamy synchronizacje ? Nic – termin ten nie pojawi się w O2 – bo trafił już do O1. Ale … (nie jest prosto – zawsze jest jakieś ALE ;) ). Załóżmy następujące operacje zachodzącą w odpowiednich czasach T

  • T0 – termin powstaje w CRM.
  • T1 – O1 jako klient synchronizacji wykonuje synchronizację danych. Termin trafia do O1
  • T2 – O2 jako klient synchronizacji wykonuje synchronizację danych. Termin NIE trafia do O2.
  • T3 – następuje edycja terminu w CRM
  • T4 – O2 jako klient synchronizacji wykonuje synchronizację danych. Termin trafia do O2
  • T5 – O1 jako klient synchronizacji wykonuje synchronizację danych. Termin NIE jest aktualizowany!!! W O1 jest ta wersja terminu, która powstała w T0

Przełączanie pomiędzy O1 a O2 spowodować może, że w końcu użytkownik nie będzie wiedział kiedy termin ma się odbyć, kiedy dane zadanie ma być wykonane – powstaje straszny bałagan. Microsoft rekomenduje, aby na stałe klientem synchronizacji był ten Outlook, który częściej jest wykorzystywany. Jak dobrze wiemy, zdarzają się sytuacje kiedy O1 i O2 wykorzystywane są w równym stopniu – wtedy pamiętajmy co możemy popsuć!.

Ad. 4: Co się dzieje kiedy chcemy śledzić termin, który powstał w Outlook ?

Termin z Outlook do CRM może być śledzony tylko wtedy kiedy jest on klientem synchronizacji. W przeciwnym przypadku po kliknięciu przycisku Śledź a następnie Zapisz dostaniemy komunikat analogiczny do tego jaki widoczny jest na screenie pierwszym. Po tym jak już termin ten znajdzie się w CRM dochodzą nam możliwości trafienia tego terminu do drugiego Outlooka, kiedy następuje modyfikacja danych poza Outlook.

Pokazane przeze mnie screeny pochodzą z CRM 4.0. Jednakże opisane scenariusze mają zastosowanie również w przypadku CRM 2011.

CRM 2011–dokąd to wszystko zmierza ….

Microsoft odłożył premierę Service Update na końcówkę tego roku. Uzasadnieniem jest m.in. duża liczba błędów zgłoszonych w czasie testów TAP. Oprócz tego w ramach Service Update zostanie dodana nowa funkcjonalność, której do tej pory nikt się nie spodziewał, nikt tego nie ogłaszał – trochę informacji na ten temat zostało ogłoszonych w czasie WPC 2012.

O co dokładnie chodzi ? Odpowiedź na to pytanie znajdziecie tutaj 

Poniżej kilka wycinków, pokazujących Dynamics CRM w wersji Metro :) – jeśli komuś przeszkadza ;) duża liczba wyskakujących okienek w Dynamics CRM to wygląda na to, że nadchodzi rewolucja :)

image image
image image

CRM + Excel

Ogromna wartość dodana posiadania Dynamics CRM to integracja z pakietem Office. Oprócz dodatku do Outlook Dynamics CRM bardzo fajnie współpracuje z Excel. Jedną z możliwości jest eksport danych.

Każdy z użytkowników (posiadając uprawnienie do eksportu danych do programu Excel) ma możliwość eksportu danych. Każda encja w Dynamics CRM posiada we wstążce Grid oraz Sub-grid przycisk służący do eksportu danych:

image

 

 

 

 

 

 

 

Kliknięcie tego przycisku spowoduje wyświetlenie okienka pozwalającego wybrać opcję eksportu danych:

image

 

  • Pierwsza opcja pozwala na eksport danych prezentowanych w wybranym widoku. Kolumny jakie są eksportowane są definiowane na poziomie widoku. Jeśli lista prezentuje dużo danych (jest więcej niż jedna strona danych) to opcja ta umożliwia eksport danych z jednej strony lub ze wszystkich stron.
  • Druga opcja (Dynamic PivotTable) to możliwość eksportu danych do tabeli przestawnej. Przy wykorzystaniu tej opcji mamy aktywny przycisk wyboru kolumn jakie będą eksportowane. Co ważne, kolumny mogą być wybrane z obiektów powiązanych z eksportowaną encją. Oznacza to, że eksportując dane o klienta możemy wyspecyfikować kolumny z encji użytkownik, klient nadrzędny. Możemy zatem poruszać się po obiektach encji nadrzędnych.
  • Trzecia opcja to eksport do arkusza dynamicznego. Arkusz dynamiczny pozwala na wybór kolumn jakie będą zamieszczone w pliku wynikowym (analogicznie do opcji 2) a dane prezentowane są w postaci arkusza (analogicznie do opcji 1).

Opcja druga oraz trzecia ma jedną ważna rzecz – jeśli poświęcimy czas na to, aby plik wynikowy odpowiednio przygotować, pokazać wykresy, zmienić formatowanie, itd. to pliki te można wykorzystać jako raport. Taki plik posiada połączenie z Dynamics CRM i korzystając z opcji odświeżenia danych w Excel możemy pobrać aktualne dane:

image

Liczba rekordów jaka zwracana jest w takim połączeniu jest ograniczone do 10 000 (limit ten można zmienić, ale jest to niewspierane!).

Oprócz tego, że plik Excel może zostać “odświeżony” może również zostać udostępniony użytkownikom jako raport w Dynamics CRM. W tym celu należy w obszarze roboczym stworzyć nowy raport wybierając jako typ raportu Istniejący plik. Dzięki temu udostępniamy plik wybranym użytkownikom oraz posiadamy jedno miejsce, w którym zarządzamy raportem – nie ma potrzeby przesyłania gotowego pliku pocztą czy też udostępniania go na różne sposoby.

O czym jeszcze nie pisałem a jest bardzo istotne to fakt, iż dane eksportowane do pliku Excel (w przypadku opcji 2 lub 3) są pobierane z widoków filtrowanych – dzięki temu użytkownicy zobaczą tylko te rekordy, do których mają uprawnienia – nie ma problemu wycieku danych :).

    CRM 2011–OnSave

    Wydawać by się mogło, że zwyczajne zdarzenie OnSave wywoływane jest w momencie kiedy użytkownik kliknie przycisk Zapisz, Zapisz i Zamknij lub też Zapisz i Utwórz nowy, który znajduje się we wstążce.
    Okazuje się, że nie tylko wtedy kod ten jest uruchamiany. Dzieję się to również kiedy chcemy obiekt dezaktywować lub aktywować jak również wtedy kiedy chcemy wykonać operację przypisania rekordu – oczywiście jeśli wykonujemy te operacje z poziomu formularza. Powstaje zatem pytanie: jak odróżnić w JS kiedy jest on uruchamiany. Można by się pokusić o sprawdzanie FormType, ale zadziała to tylko w przypadku aktywacji obiektu bo możemy sobie zobaczyć, że formularz jest wtedy tylko do odczytu. Dla pozostałych operacji zawsze będziemy mieli typ formularza Update.
    Jest na szczęście wspierane (to moje ulubione stwierdzenie :D) rozwiązanie tej zagadki. W czasie kiedy konfigurujemy zdarzenie OnSave widzimy na formularzu następujące coś:
    image
    Co się dzieje kiedy zaznaczymy ten checkbox ? Po pierwsze nasza funkcja musi być odpowiednio zmodyfikowana i wyglądać powinna mniej więcej tak:
    image
    A co daje nam ten parametr ? Widać to już na obrazku wyżej: eContext.getEventArgs().getSaveMode() – pozwala nam na “dobranie” się do wartości, które pomogą nam w zrozumieniu co jest powodem wystąpienia operacji Zapisz. Te numerki, które widać na obrazku są do odnalezienia w SDK. Na wszelki wypadek zamieszczam je tutaj (wartości pochodzą z SDK opublikowanego 2.12.2011 :) – kto wie czy będą w przyszłości zmienione):
    Entity Event Mode Value
    All Save 1
    All Save and Close 2
    All Save and New 59
    Activities Save as Completed 58
    All Deactivate 5
    All Reactivate 6
    User or Team owned entities Assign 47
    Email (E-mail) Send 7
    Lead Qualify 16
    Lead Disqualify 15

    Dostęp do raportów w CRM

    Czasami zdarza się, aby dostęp do specyficznych raportów dostęp mieli tylko konkretni użytkownicy lub też aby domyślne raporty dostępne w CRM były poukrywane przed większością użytkowników. Jak do tego podejść ?

    Raport w Dynamics CRM jest prawie takim samym obiektem jak Klient czy Kontakt. Powoduje to, iż konfigurując uprawnienia możemy zdecydować czy użytkownik może widzieć tylko swoje raporty, raporty wszystkie (w całej organizacji):

    image

    Z drugiej jednak strony napisałem, że Raport jest prawie jak Klient czy Kontakt. To prawie polega na tym, że w ustawieniach raportu możemy określić czy raport jest indywidualny czy też dostępny w organizacji.

    image

    Co to właściwie znaczy ? A dokładnie to, że ustawienie na Organizacja powoduje, że raport jest dostępny nawet dla tych użytkowników, którzy mają dostęp w uprawnieniach tylko do swoich raportów. Jeśli Raport ustawiony jest jako Indywidualny to dostępny jest dla właściciela raportu, tych komu jest on udostępniony oraz tych, których rola daje dostęp do tego raportu.

    Patrząc z drugiej strony – jeśli użytkownik ma dostęp tylko do swoich raportów to widzi on naprawdę następujące raporty:

    • Te, których jest właścicielem
    • Te, które są mu udostępnione
    • Te, które są ustawione jako raporty Organizacyjne.

    Filtrowane pola typu Lookup

    W CRM 4.0 w większości projektów trzeba było tworzyć niewspierane rozwiązanie, które pomagało korzystać z filtrowanych pól typu Lookup. Przykładem takiego zastosowania było np. umieszczenie na formularzu klienta powiązania z bazą kodów pocztowych. Zamiast polegać na tym, aby użytkownicy CRM sami wprowadzali wartości w polach budowany był słownik kodów pocztowych. Słownik ten miał również dodatkowe informacje takie jak województwo czy też powiat (również w postaci słownika). Na formularzu klienta umieszczane były pola Kod Pocztowy, Powiat, Województwo. Wybranie np. województwa powodować powinno zawężenie wartości w słowniku Powiat oraz Kod Pocztowy do wartości z danego województwa.

    W CRM 2011 Microsoft zaimplementował wsparcie dla tego typu funkcjonalności i filtrowane lookupy stały się wspierane “z pudełka”. Konfigurując pola typu lookup na formularzu można wybrać sobie czy ma to pole być filtrowane czy też nie. A jeśli ma to na podstawie jakiego pola – uwaga – tylko jednego:

    image

     

     

     

     

     

    W większości przypadków wykorzystanie filtrowania po jednym polu wystarczy. Gdyby jednak to było za mało mamy do dyspozycji coś co powala i czego nie było w poprzedniej wersji CRM. Możemy sami definiować sobie widok jaki będzie pokazywany w oknie wyszukiwania (po kliknięciu lupki w polu typu lookup). Jak to się robi ?

    Pisze się odpowiedni kod w JS i umieszcza jego wykonania np. w zdarzeniu OnLoad formularza. Definiując taki kod określamy przede wszystkim kryteria wyszukiwania (w postaci FetchXML) oraz tego jak ma być prezentowany widok – czyli określamy jakie kolumny, w jakiej szerokości mają prezentować się w okienku wyszukiwania. W efekcie możemy otrzymać filtrowany lookup bez ograniczeń. Przykładowe zastosowanie tego mechanizmu: rejestrujemy w CRM szanse sprzedaży, ale dla jednej szansy sprzedaży można dowiązać wielu klientów (relacja N:1 pomiędzy szansą sprzedaży a klientem). Następnie na formularzu szansy chcemy wskazać jedną osobę kontaktową (Kontakt), która będzie wskazywać osobę decyzyjną spośród wszystkich osób kontaktowych wszystkich klientów biorących udział w szansie sprzedaży. Aby pokazać w oknie wyszukiwania tylko te osoby kontaktowe, które dowiązane są do klientów dowiązanych do szansy sprzedaży korzystamy właśnie z kodu JS.

    Przykładowy kod wygląda następująco:

    image

    Po więcej szczegółów odsyłam do SDK – słowo kluczowe do znalezienia to addCustomView :)

    CRM 2011 i jego dostosowywanie

    Wydawać się by mogło, że nowa wersja CRM usprawni edycję takich dostosowań jak znana z CRM 4.0 mapa witryny (sitemap) czy też ISV.config. Ten pierwszy plik w nowej wersji CRM nie został zmieniony natomiast ISV.config zastąpiony został plikiem xml definiującym elementy wstążki. Wstążka to zupełnie nowa rzecz, która wykracza daleko poza możliwości starego ISV.config. Nowe możliwości niosą za sobą rozbudowaną strukturę, bardziej skompilowanie definicje pliku xml czy też rozbicie wstążki na poszczególne encje – kto miał do czynienia z dodaniem przycisku do wstążki ten wie o czym mowa ;)

    Niestety Microsoft nie zaprezentował narzędzia, które pozwoli na łatwą edycję zarówno mapy witryny jak też wstążki. Na szczęście społeczność Dynamics CRM nie śpi i na codeplex znaleźć można dwa fajne narzędzia:

    1. http://sitemapeditor.codeplex.com/

      SiteMapEditor

    2. http://ribboneditor.codeplex.com/

      RibbonEditor

     

    Pamiętać jednak należy, że są to narzędzia, które mogą działać niestabilnie i trzeba wiedzieć co kryje się pod maską CRMa aby, jeśli będzie to konieczne, naprawić to co zostanie zepsute :)