wtorek, 13 grudnia 2011

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

sobota, 10 grudnia 2011

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.

wtorek, 4 października 2011

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

sobota, 16 lipca 2011

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

wtorek, 17 maja 2011

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:

image

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

image

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

image

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

czwartek, 28 kwietnia 2011

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

piątek, 8 kwietnia 2011

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:

image

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

image

image

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:

image

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:

image

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

image

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:

image

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:

image

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:

image

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