Uprawnienia CRM (Create)

Każde wdrożenie Dynamics CRM wiąże się z konfiguracją ról. Idealne podejście to takie kiedy użytkownik otrzymuje minimalne uprawnienia jakie są mu potrzebne do pracy. Jednakże kiedy konfiguracja ról zmienia się wraz z życiem systemu, może dojść do sytuacji kiedy role konfigurowaną są “na czuja”, przywileje nadawane są “aby działało”.

Poniższy wpis dla niektórych może być powtórką z rozrywki a dla niektórych stanowić może podsumowanie wiedzy, którą posiada. O czym będzie ? Odpowiemy sobie na pytanie: Co oznacza w matrycy uprawnień uprawnienie Create? Czy aby utworzyć komuś rekord muszę mieć możliwość przypisania rekordu (Append, Append To) do użytkownika ? Czy aby zmienić właściciela muszę mieć uprawnienie przypisania rekordu do użytkownika ? Itd. Być może odpowiedź jest trywialna, ale jak pokazuje doświadczenie i przegląd gotowych wdrożeń – nie zawsze tak jest :).

Zacznijmy więc od początku – czym jest rola w Dynamics CRM ? Rola to zbiór uprawnień wraz z poziomem uprawnień. Uprawnienie określa co możemy zrobić w kontekście danej encji (np. tworzenie Kontaktu). Poziom uprawnień określa zakres działania uprawnienia (np. możemy czytać tylko te kontakty, których jesteśmy właścicielem lub też możemy czytać wszystkie z całej organizacji).

Dynamics CRM udostępnia następujące uprawnienia oraz poziomy uprawnień:

Uprawnienia	Poziomy Uprawnień
Create Read Write Delete Append Append To Assign Share	None User Business Unit Parent/Child Business Unit Organization

Dla jednej encji możemy zatem mieć baaaaardzo dużo możliwości ustawienia roli. Zacznijmy od prostego przypadku – chcemy nadać użytkownikowi uprawnienia do tego, aby mógł tworzyć rekordy encji Account dla innych użytkowników.

Uprawnienie Create samego nie można nadać – bo aby móc w interfejsie użytkownika Dynamics CRM zobaczyć SubArea Account należy mieć prawo odczytu. Ustalamy zatem, że rola ma “na dzień dobry” odczyt na poziomie jednostki biznesowej. Idąc dalej chcemy nadać uprawnienia do tworzenia w połączeniu z uprawnieniami dla encji SystemUser (poniższa tabela nie przedstawia wszystkich kombinacji):

Poziom	Opis	Uprawnienia Read dla encji SystemUser (pozostałe ustawione na None)	Rezultat
None	Użytkownik nie będzie miał praw do tworzenia rekordów encji Account. Brak przycisku utworzenia nowego rekordu w Dynamics CRM	n.d.	n.d.
User	Użytkownik ma prawo do tworzenia rekordów encji Account. Przycisk “New” jest widoczny w Dynamics CRM. Na formularzu pole Owner jest edytowalne.	n.d.	Niezależnie od ustawień poziomu uprawnień dla odczytu encji SystemUser próba zapisania kończy się komunikatem: brak uprawnień do wykonania tej akcji …
Business Unit	Użytkownik ma prawo do tworzenia rekordów encji Account. Przycisk “New” jest widoczny w Dynamics CRM. Na formularzu pole Owner jest edytowalne.	None	Nie można odczytać użytkowników – nie można wybrać innego
Business Unit	Użytkownik ma prawo do tworzenia rekordów encji Account. Przycisk “New” jest widoczny w Dynamics CRM. Na formularzu pole Owner jest edytowalne.	Business Unit	Próba kończy się sukcesem. Wskazać można tylko użytkowników ze swojej jednostki biznesowej
Business Unit	Użytkownik ma prawo do tworzenia rekordów encji Account. Przycisk “New” jest widoczny w Dynamics CRM. Na formularzu pole Owner jest edytowalne.	Parent/Child Business Unit Organization	Dla użytkowników z tej samej jednostki biznesowej sukces Dla użytkowników z jednostek podrzędnych próba zapisania kończy się komunikatem: brak uprawnień do wykonania tej akcji …
Parent/Child Business Unit	Użytkownik ma prawo do tworzenia rekordów encji Account. Przycisk “New” jest widoczny w Dynamics CRM. Na formularzu pole Owner jest edytowalne.	Parent/Child Business Unit	Jeśli właściciel jest z jednostki podrzędnej próba kończy się sukcesem, ale występuje błąd bo chcemy odczytać Account, którego nie możemy odczytać bo uprawnienia Read mamy na poziomie swojej jednostki biznesowej.
Parent/Child Business Unit	Użytkownik ma prawo do tworzenia rekordów encji Account. Przycisk “New” jest widoczny w Dynamics CRM. Na formularzu pole Owner jest edytowalne.	Organization	Jeśli właściciel jest z jednostki podrzędnej próba kończy się sukcesem, ale występuje błąd bo chcemy odczytać Account, którego nie możemy odczytać bo uprawnienia Read mamy na poziomie swojej jednostki biznesowej. Jeśli właściciel jest z niepowiązanej jednostki biznesowej to próba kończy się komunikatem: brak uprawnień do wykonania tej akcji …
Organization	Użytkownik ma prawo do tworzenia rekordów encji Account. Przycisk “New” jest widoczny w Dynamics CRM. Na formularzu pole Owner jest edytowalne.	n.d.	Próba kończy się sukcesem. Wskazać można tylko użytkowników, do których ma się prawo odczytu.

Wnioski: Uprawnienie Create daje możliwość stworzenia rekordu “komuś” – ten ktoś określany jest na podstawie tego jakich użytkowników możemy odczytać a nie do jakich użytkowników mamy uprawnienia Append To albo czy mamy uprawnienia Append na encji Account czy też nie. Minimalny zestaw uprawnień, na których powinniśmy się skupić to Read (dla encji SystemUser oraz Account) oraz Create (dla encji Account). Dodatkowo: nowy właściciel musi mieć co najmniej prawo do odczytu Account aby móc stać się właścicielem. Dynamics CRM nie pozwoli przypisać konta użytkownikowi, który nie ma do tej encji żadnych uprawnień – kiedy nie ma w roli lub kiedy jest dezaktywowany.

 

Powyższa tabela przedstawia w formie kolorystycznej to co wcześniejsza tabela opisuje ;) Kolor żółty przedstawia sytuacje kiedy odpowiedzią na pytanie “czy zadziała” będzie odpowiedź “to zależy … jakiego użytkownika wybierzesz”.

Importowanie notatek

Jedną z rzeczy, które mi osobiście się podobają w CRM 2011 jest opcja importu danych z plików. Funkcjonalność ta, która jest oczywiście dostępna w wersji 4.0, tutaj nabrała nowego kształtu. Jest to narzędzie intuicyjne, proste w obsłudze (szczególnie przez użytkowników biznesowych) oraz posiadające duże możliwości.

To co chciałbym dzisiaj opisać to możliwość importu notatek, która posiadają dokument w formie załącznika. Na początku kilka słów o samych notatkach.

Encja annotation jest powiązana z większością standardowych obiektów w CRM. Może być też wykorzystywana w powiązaniu z encjami niestandardowymi. Dodając notatkę mamy możliwość wpisania notatki tekstowej oraz dołączenia do niej dokumentu. Zawartość dokumentu (jego body) jest w bazie CRM przechowywane jako łańcuch znaków zakodowanych w Base64, w kolumnie typu varchar(max). W czasie dodawania dokumentu CRM sam określa jaki jest rozmiar pliku, content type, itd i zapisuje te informacje w bazie CRM.

Jednakże dokument taki jest obarczony ograniczeniami CRM jeśli chodzi o rozmiar pliku jaki może być w nim przechowywany.

Dokumenty w postaci notatek mogą być importowane z wykorzystaniem standardowego mechanizmu importu w Dynamics CRM 2011. Aby to zrobić musimy przygotować następujące archiwum *.zip:

• katalog o nazwie attachments, który zawierać będzie dokumenty, które chcemy dodać do CRM (ważne aby zwrócić uwagę na polskie znaki w nazwie pliku).
• plik (np. csv lub txt), który przykładowo będzie zawierać następujące kolumny (większej liczby nie trzeba)
  • Tytuł – jest to wymagane w czasie tworzenia notatki
  • Opis – treść notatki, np. krótki opis dołączanego dokumentu. Nie jest to zwartość dokumentu.
  • Nazwa pliku – treść jaka będzie prezentowana w CRM jako link do dokumentu. Nie musimy tego wypełniać, jednakże w CRM zobaczymy zamiast prawdziwej nazwy pliku np. Untitled.txt
  • Nazwa dokumentu – nazwa dokumenty z katalogu attachments, który będzie do notatki przypisany. To musimy wskazać
  • Właściciel – nie musimy tego wskazywać, ale można tutaj określić kto ma być właścicielem notatki w CRM
  • Rekord powiązany – do jakiego rekordu chcemy dowiązać notatki – np. klient, kontakt, itp

Mając przygotowane takie archiwum można wykonać standardowy import. Jak już zostało to wcześniej zaznaczone w momencie importu danych z pliku, który został umieszczony w archiwum, Dynamics CRM będzie szukał w katalogu attachments plików określonych w kolumnie Nazwa dokumentu. Jeśli dokument nie zostanie znaleziony to notatka nie zostanie utworzona w CRM. Zostanie zarejestrowany błąd informujący to braku możliwości znalezienia odwołania do pliku.

Na co należy jeszcze zwrócić uwagę ? Na to, że nie należy wskazywać w pliku kolumny, w której określać będziemy typ pliku, jego rozmiaru, ,rozszerzenia, itd – wszystko to wykona za nas CRM – dzięki temu użytkownicy biznesowi nie przestraszą się tego narzędzia.

Dodatkowa rzecz to taka, iż importowane archiwum nie może przekraczać limitu jaki nałożony jest na importowany plik (ok 8MB). Jeśli chcemy wykonać import dużych plików lub dużej liczby małych plików to musimy przygotować się na konieczność tworzenia wielu archiwów.

Xrm.Utility.openEntityForm

Update Rollup 8 dla Dynamics CRM 2011 przyniósł meeeega fajną funkcjonalność JScript. Do tej pory aby, korzystając z JS, otworzyć formularz obiektu trzeba było zbudować odpowiedni URL a następnie wykorzystać metodę window.open(….).

Obecnie jest dostępna fajniejsza metoda polegająca na wywołaniu funkcji: Xrm.Utility.openEntityForm. Funkcja ta ma następujące możliwości:

• Jeśli wykonany zostanie następujący kod: Xrm.Utility.openEntityForm(“account”); zostanie zaprezentowany formularz tworzenia rekordu encji account
• Jeśli wykonany zostanie następujący kod: Xrm.Utility.openEntityForm(“account”, “<identyfikator klienta>”); zostanie zaprezentowany formularz wskazanego rekordu encji account.

Funkcja ta działa zarówno dla encji systemowych jak również dla encji niestandardowych. Wygląd formularza jest identyczny gdybyśmy otworzyli rekord z listy rekordów lub kliknęli przycisk Nowy w celu utworzenia nowego rekordu (nie jest prezentowane menu przeglądarki, nie jest wyświetlany komunikat o tym, że chcemy zamknąć okno przeglądarki kiedy chcemy zamknąć formularz, itd – same zalety :) ). Wystarczy tylko zainstalować UR8.

Publikowanie (niedużego) rozwiązania i … timeout :/

Kiedy serwery są obciążone dojść może do sytuacji kiedy próba publikacji lub importu rozwiązania w Dynamics CRM zakończy się niepowodzeniem. Dokładne sprawdzenie w logach CRM (/Program Files/Microsoft Dynamics CRM/Trace) uświadomi nas, że mamy do czynienia z timeout’em. Na szczęście CRM pozwala na modyfikację niektórych parametrów związanym z czasem wykonania operacji. Niestety niektóre z opisanych poniżej modyfikacji jest niewspieranych, ale niestety bez nich nie uda się problemu rozwiązać.

Pierwsze miejsce (wspierane) gdzie należy ustawić parametry to rejestr. W kluczu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM ustawić należy następujące klucze

• OLEDBTimeout – określa wartość dla pojedynczego zapytania SQL. Wartość wyrażona w sekundach. Domyślnie 30 sekund
• ExtendedTimeout – określa wartość dla ASP.NET. Wartość wyrażona w milisekundach. Domyślnie 1 000 000 milisekund
• NormalTimeout – określa wartość dla SOAP. Wartość wyrażona w milisekundach. Domyślnie 300 000 milisekund

Jeśli to nie pomoże należy zmodyfikować plik web.config (niewspierane) znajdujący się w katalogu CRMWeb (u mnie: /Program Files/Microsoft Dynamics CRM/CRMWeb)

Zmienić należy wartość domyślną (300) parametru executionTimeout na inną – ja ustawiłem 3600 – sekund. Parametr ten określa po jakim czasie żądanie ASP.NET zostanie “zabite”.

Jeśli i to nie pomoże pozostaje nam ostatni parametr (niewspierane), który modyfikuje się w bazie MSCRM_CONFIG w tabeli DeploymentProperties. W tabeli tej szukamy rekordu, który w kolumnie ColumnName ma wartość SqlCommandTimeout

Wartość domyślna tego parametru to 30. Wartość wyrażona jest w sekundach.

CRM 2011–przenoszenie Plugin’ów

Jedną z wielkich zalet Dynamics CRM jest możliwość tworzenia pluginów. Nie jest to nowością w CRM 2011, ale w nowej wersji platformy mamy nowe możliwości “zabawy” z nimi.

Zabawa związana jest z przenoszeniem pluginów pomiędzy organizacjami. Plugin może być częścią rozwiązania w Dynamics CRM:

1. Plugin-in Assemblies
2. Sdk Message Processing Steps

Do solucji można dodać to, co wcześniej zarejestruje się przy pomocy Plugin Registration Tool (PRT). Niby oczywiste, ale nie zawsze jest oczywiste co się dzieje z krokiem (stepem) kiedy jest on uruchamiany w konktekście konkretnego użytkownika (inny niż Calling User) ? W momencie importu rozwiązania do organizacji szukany jest użytkownik o takiej samej pełnej nazwie (!!! a nie nazwie logowania do domeny). Jeśli nie zostanie znaleziony krok jest konfigurowany tak, aby uruchamiał się w kontekście Calling User. Informacja o tym jest logowana w czasie importu rozwiązania – dlatego warto weryfikować go za każdym razem kiedy wykonujemy import pluginów – gdyż wszelki błąd w konfiguracji objawi się zapewne dopiero kiedy “zwykli” użytkownicy zabiorą się za pracę w CRM.

Jeśli rejestrujemy Plugin, który będzie znajdować się w katalogu /assembly to przed zaimportowaniem rozwiązania musimy skopiować biblioteki do tego katalogu. Proces importu tego wymaga.

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:

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:

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ś:

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 :)

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:

 

 

 

 

 

 

 

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

 

• 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:

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ś:

Co się dzieje kiedy zaznaczymy ten checkbox ? Po pierwsze nasza funkcja musi być odpowiednio zmodyfikowana i wyglądać powinna mniej więcej tak:

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):

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.

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:

 

 

 

 

 

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:

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/

   

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

   

 

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 :)

CRM 2011–Ukrywanie widoków systemowych

Kto miał za zadanie ukryć widoki systemowe w CRM 4.0 ten wie jakie to było problematyczne :) Co się zmieniło w nowym CRM ? Podobnie jak np. klienta może być aktywny lub nieaktywny tak samo widoki. Z poziomu dostosowań możemy oznaczyć widok jako aktywny/nieaktywny:

Po dezaktywacji widok będzie widoczny w liście widoków nieaktywnych:

Po wyłączeniu kilku widoków i opublikowaniu zmian w efekcie dostajemy przykładową listę widoków:

Efekt osiągnięty w prosty sposób co w CRM 4 zajmowało czas na napisanie pluginu, który przestawał działać kiedy ktoś przypadkiem zmienił nazwę widoku :)

CRM 2011–pierwszy egzamin MB2-866

Na stronie Microsoft Learning znaleźć można już informacje o egzaminie związanym z Dynamics CRM 2011: MB2-866: Microsoft Dynamics CRM 2011 Customization and Configuration. Szczegółowe informacje znaleźć można na stronie ML: http://www.microsoft.com/learning/en/us/exam.aspx?ID=MB2-866

CRM 2011–Kolejki w CRM

Kto korzystał z kolejek w CRM 4.0 ten wie jak wiele ograniczeń ten mechanizm tam posiada. Przykładowo dostępu do kolejek nie dało się ograniczyć, tzn. jeśli organizacja była podzielona na wiele jednostek organizacyjnych to nie było możliwości ukrycia kolejek pomiędzy tymi jednostkami. W CRM 4.0 kolejki są “Organization-owned” (mówimy oczywiście o kolejkach publicznych a nie kolejkach private oraz WIP, które tworzone są dla każdego użytkownika bez udziału i możliwości ingerencji użytkownika) co znaczy, że nie jest ona przypisana do konkretnej osoby, tylko do jednostki biznesowej. W nowym CRM kolejka jest “User-owned” co powoduje, że właściciel widoczny w CRM 4.0 na formatce kolejki w CRM 2011 jest faktycznie jego właścicielem:

Ma to swoje przełożenie również na uprawnienia:

W definicji roli możemy określić zakres widoczności kolejek: możemy widzieć tylko swoje kolejki jak również kolejki swojego zespołu. Trzeba tutaj wspomnieć, że domyślnie kolejki tworzone są dla nowego użytkownika, dla nowego zespołu.

Kolejna super sprawa związana z kolejkami to fakt, iż możemy do nich “wrzucić” różnego typu obiektu. Wystarczy w części poświęconej dostosowaniom obiektu wskazać, że chcemy aby ten obiekt mógł być umieszczany w kolejce:

Dodatkową opcją jest możliwość automatycznego umieszczenia elementu w kolejce właściciela jeśli obiekt jest dla niego tworzony lub też właściciel obiektu się zmienia.

Po ustawieniu tej opcji pojawią się we wstążce dodatkowe przyciski pozwalające na wysłanie obiektu do kolejki oraz podejrzenie tego obiektu w kolejce. Na liście obiektów mamy do dyspozycji jeden przycisk do dodania obiektu do kolejki:

Z kolei na formatce mamy do dyspozycji dwa przyciski. Jeden do dodania elementu, drugi do wyświetlenia obiektu w kolejce.

Będąc przy podglądaniu obiektu w kolejce widzimy kolejną nowość w CRM 2011. Został udostępniony nowy obiekt “Queue Item”, który przechowuje referencje do obiektu, kolejki oraz osoby, aktualnie odpowiedzialnej za ten element – co najważniejsze jest to obiekt dostosowywalny co pozwala np. na zbudowanie procesów sprawdzające SLA rozwiązywania spraw, co w wielu wdrożeniach CRM 4.0 było wymaganiem bardzo ciężkim do zrealizowania, a który w nowym CRM jest już łatwiejsze:

Proces wysłania obiektu do kolejki polega na stworzeniu nowego obiektu Queue Item (Element Kolejki), nie ma czegoś takiego co było w CRM 4.0, że obiekt jest “przypisywany do kolejki” co tak naprawdę skutkowało udostępnieniem obiektu dla wskazanej kolejki. Jeśli chcemy zautomatyzować dodawanie obiektu do kolejki (np,. w przepływie pracy) to musimy stworzyć nowy obiekt element kolejki. Jak mamy ten obiekt to możemy pisać pluginy, które wspierają nam procesowanie spraw na podstawie SLA lub też przepływy, które będą notyfikować osoby/zespoły, że w ich kolejce powstało nowe zgłoszenie.

Chcąc zaprezentować elementy w kolejkach korzystamy z kolejek dostępnych w Obszarze Roboczym:

Możemy z tego poziomu wybrać sobie kolejkę, którą chcemy przeglądać (lub prezentujemy elementy ze wszystkich kolejek). Możemy również wybrać widok, który prezentuje elementy czekające na przypisanie oraz elementy przypisane:

We wstążce zobaczymy następujące elementy:

1. Routing – przycisk ten służy do przesłania wybranego elementu z kolejki do innej kolejki. Można przy tej okazji zmienić osobę, która aktualnie pracuje nad elementem.
2. Pracuj nad – powoduje ustawienie pola Pracownik na formatce elementu kolejki. Można wskazać użytkownika lub też zespół.
3. Zwolnij – powoduje wyczyszczenie pola Pracownik na formatce elementu kolejki. Element trafia do widoku “Elementy dostępne do opracowania”.
4. Usuń – powoduje usunięcie elementu kolejki. Sam obiekt, który został wysłany do kolejki nie jest usuwany.
5. Szczegóły elementu kolejki – powoduje wyświetlenie formatki elementu kolejki.

Pozostaje już tylko wykorzystać tę wiedzę w prawdziwym wdrożeniu :)

CRM 2011–Dashboard “Restrict cross-frame scripting”

W CRM 2011 wbudowana została nowa funkcjonalność, pozwalająca na tworzenie tzw. dashboard’ów dla użytkowników końcowych. Wszystko to ma na celu udostępnienie użytkownikom jak najbogatszego pakietu, który może być przez nich samych dostosowywany. Mając tę funkcjonalność dostępną “z pudełka” każdy może ustawić sobie jako panel startowy dowolny raport/wykres/listę – w zależności od upodobań.

W takiej tablicy można umieścić wykres, element iframe, listę czy też dowolny Web Resource. Jako element iframe można umieścić odnośnik do raportu, który zbudowany jest w organizacji i już od dawna wykorzystywany. Jednakże tutaj powstaje problem. Element iframe może mieć włączone zabezpieczenie związane z cross-site scripting. Użytkownik biznesowy nie może tej opcji wyłączyć:

Jest to dobre podejście, gdyż jeśli każdy użytkownik by miał możliwość dodawania linków na tablicy do dowolnego źródła w Internecie to by miało to wpływ na bezpieczeństwo systemu CRM – po co ryzykować pomyślał Microsoft i tę opcję wyłączył. Jednak co z przypadkiem, który opisałem wyżej – co kiedy chcemy w CRM pokazać raport, który organizacja od dawna wykorzystuje i jest do niego przyzwyczajona tak bardzo, że brak jego w CRM to poważna strata ?

Na szczęście tablice tworzone przez Administratora z poziomu Solution pozwala na wyłączenie opcji cross-site scripting:

Wierzymy, że administrator jest świadomy tego co robi :)

CRM 2011–wysyłanie widomości email–zatwierdzanie adresów email

Jeśli spojrzymy sobie na dwa aspekty nowego CRM: Ustawienia systemowe oraz formatkę użytkownika to zobaczymy tam dwie nowe rzeczy, których nie było w CRM 4.0:

Obie rzeczy dotyczą wysyłki wiadomości email z wykorzystaniem Email routera. W ustawieniach systemowych można wymóc, aby CRM e-mail router procesował tylko te wiadomości email, których nadawcy mają zatwierdzony przez administratora adres. Drugi zrzut ekranu pokazuje dwa przyciski na formatce użytkownika “Approve E-mail” oraz “Reject E-mail”. Przy ich pomocy administrator może zatwierdzić lub też odrzucić adres email przy pomocy, którego będzie odbywać się wysyłka wiadomości email.

Jeśli użytkownikowi ustawimy opcję dostępu do poczty email jako E-mail Router to jeśli jego adres mailowy nie zostanie zatwierdzony zostanie zaprezentowany na jego formatce następujący komunikat:

CRM 2011–Pluginy i namiastka z CrmSvcUtil

Korzystamy sobie z usługi sieciowej CRM 2011, budujemy własną strukturę obiektów, generujemy z tego namiastkę, wrzucamy wszystko do pluginu i …. patrzymy na błąd:

Unable to cast object of type 'Microsoft.Xrm.Sdk.Entity' to type 'Netwise.Crm.Sdk.Account'.

I co teraz ? Czy wszystko muszę przerobić na Entity i bawić się indekserami ? To tylko jedno podejście. Inne podejście, które może nas uchronić od tego pierwszego to wykorzystanie generycznej metody ToEntity<>. Zamiast kodu:

return (Account)service.Retrieve(Account.EntityLogicalName, accountId, new ColumnSet(Attributes.accountnumber));

Napiszemy kod:

return service.Retrieve(Account.EntityLogicalName, accountId, new ColumnSet(Attributes.accountnumber)).ToEntity<Account>();

Wtedy nasza początkowa praca nie pójdzie na marne i nie będziemy oglądać wyjątku.
Z kolei jak chcemy tworzyć obiekty przy pomocy IOrganizationService w pluginie nie musimy korzystać z Entity tylko możemy korzystać z wygenerowanych klas. Przykładowo tworząc nowego klienta zamiast pisać kod:

service.Create(_account);

Musimy zrobić:

service.Create(_account.ToEntity<Entity>());

W przypadku pierwszego kodu otrzymamy podobny błąd o rzutowaniu Account na Entity. Drugi kod zadziała bez problemu

CRM 2011 RC–czas ma znaczenie :)

Przesiadka ze środowiska Beta na RC spowodowała, że uruchomienie kodu narzędzia korzystającego z usług CRM 2011 zakończyło się następującym komunikatem błędu

System.ServiceModel.Security.MessageSecurityException : An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. System.ServiceModel.FaultException : An error occurred when verifying security for the message.

Szukam powodu tego błędu: generuję namiastkę dla wersji RC, przebudowuję projekt, itd, a okazuje się, że CRM nie ma z tym nic wspólnego – błąd ten jest związany z WCF. Wynika z tego, iż maszyna, na której znajduje się serwer przez przypadek nie posiada poprawnie ustawionego czasu :) – naprawienie tej prostej zależności rozwiązało problem narzędzia i przesiadki na nową wersję.

CRM 2011–skrypty i FormType

Pisząc skrypty JScript do obsługi zdarzeń OnLoad, OnSave czy też OnChange możemy korzystać również z dobrze znanej w CRM 4 referencji do crmForm. To podejście zostało pozostawione w CRM 2011 w celu zachowania kompatybilności. Zaleca się jednak korzystanie z referencji do Xrm.Page.

Pisząc jeden skrypt potrzebowałem informacji na temat tego jakiego typu formatka jest prezentowana. W CRM 4.0 wystarczyło skorzystać z następującego kodu: crmForm.FormType. W CRM 2011 jest inaczej (oczywiście jeśli będziemy korzystać z Xrm.Page). W CRM 2011 trzeba wykonać następujący kod: Xrm.Page.ui.getFormType(). Argumentem zwracanym przez tą metodę jest liczba całkowita, podobnie jak crmForm.FormType.