W tym wpisie chciałbym przedstawić jak z pomocą narzędzi Power Platform, SharePoint oraz usługi Document Inteligence zbudowałam kompletne rozwiązanie umożliwiające w pełni zautomatyzować proces obsługi faktur - od dodania faktury, przez analizę dokumentu, aż po zapisanie danych w SharePoint.

1. Scenariusz przetwarzania faktur

Załóżmy, że w naszej firmie proces obsługi faktur wygląda standardowo – użytkownik otrzymuje dokument, wprowadza dane ręcznie do systemu, a następnie księgowość weryfikuje poprawność i status każdej faktury. Jest to czasochłonne, podatne na błędy i trudne do monitorowania, szczególnie gdy liczba dokumentów rośnie.

Aby usprawnić cały proces, możemy rozłożyć go na kilka kluczowych kroków, które zostaną w pełni zautomatyzowane przy użyciu Power Platform, SharePoint i Azure Document Intelligence:

1. Użytkownik dodaje fakturę przez aplikację Power Apps.

2. Power Automate zapisuje dokument w bibliotece SharePoint i tworzy nowy rekord na liście.

3. Dokument trafia do Azure Document Intelligence, gdzie zostaje przeanalizowany.

4. Wynik analizy wraca w formacie JSON i jest parsowany w Power Automate.

5. Rekord w SharePoint zostaje uzupełniony o rozpoznane dane, a jego status zmienia się na “Processed”.

6. W przypadku błędu, status elementu aktualizuje się na “Error”, co pozwala szybko wychwycić nieprawidłowości.

2. Elementy rozwiązania

Rozwiązanie zostało zbudowane na kilku elementach ekosystemu Microsoft.

2.1. Power Apps (Canvas App)

Power Apps pełni rolę interfejsu wejściowego – w naszej aplikacji użytkownik wprowadza fakturę, a po zatwierdzeniu pliku uruchamiany jest przepływ w Power Automate.

If(
    CountRows(AttachInvoice.Attachments) = 0,
    Notify(
        "Wybierz plik przed zatwierdzeniem.",
        NotificationType.Error
    ),
    Set(
        _att,
        First(AttachInvoice.Attachments)
    );
    SaveInvoiceAndAnalyze.Run(
        {
            name: _att.Name,
            contentBytes: _att.Value
        }
    );
    Notify(
        "Faktura została przesłana do systemu.",
        NotificationType.Success
    );
    Reset(AttachInvoice);

)

Warto podkreślić, że w tym projekcie Power Apps pełni jedynie rolę symulacji zewnętrznego źródła danych – w rzeczywistych scenariuszach ten krok mógłby zostać zastąpiony innym systemem, np. platformą ERP, systemem CRM, dedykowanym portalem dla klientów czy nawet zewnętrzną aplikacją integrującą się przez API. Dzięki temu rozwiązanie pozostaje elastyczne i można je dostosować do różnych potrzeb biznesowych.

2.2. SharePoint

SharePoint pełni dwie funkcje w rozwiązaniu:

• Biblioteka dokumentów „DokumentyFaktur” – tutaj przechowywane są wszystkie przesłane faktury w formie plików.

• Lista „Faktury” – służy do przechowywania danych faktur. Lista zawiera kolumny takie jak:

  • Title - tytuł rekordu

  • InvoiceNumber - numer faktury

  • IssuedTo - osoba dla której wystawiono fakturę

  • DueDate - termin płatności faktury

  • Tax - wartość podatku

  • Total - łączna wartość faktury

  • Status - pole Choice określające status - “New“ (wartość domyślna, nadawana w momencie utworzenia rekordu faktury), “Processed“ (wartość nadawana po przetworzeniu faktury), “Error“ (wartość nadawana w momencie błędu przy przetwarzaniu faktury)

  • FileLink - link do pliku faktury w bibliotece “DokumentyFaktur“

    

2.3. Power Automate

Power Automate pełni rolę centrum całego procesu. Flow odpowiada za:

• zapisanie pliku w bibliotece SharePoint,

• utworzenie rekordu na liście faktur,

• przesłanie dokumentu do usługi Azure Document Intelligence,

• parsowanie zwróconego JSON-a i wyciągnięcie kluczowych wartości (numer faktury, termin płatności, kwoty itp.),

• aktualizację rekordu w SharePoint z odpowiednim statusem (Processed lub Error).

Dzięki Power Automate proces przebiega w pełni automatycznie, a każdy rekord faktury ma przypisany aktualny status i powiązany plik w bibliotece.

2.4. Azure AI Document Intelligence

Usługa Document Intelligence odpowiada za automatyczną analizę zawartości dokumentu. W moim projekcie wykorzystałam własny model trenowany na przykładowych fakturach, który umożliwia odczytywanie:

• numeru faktury,

• osoby dla której faktura została wystawiona

• terminu płatności,

• wartości podatku i kwoty całkowitej.

3. Custom model w Document Intelligence

Azure Document Intelligence to narzędzie oparte na sztucznej inteligencji, które umożliwia automatyczne odczytywanie danych z dokumentów, takich jak faktury, paragony czy formularze. Usługa pozwala na szybkie przetwarzanie dokumentów i wyciąganie kluczowych informacji w formacie JSON, gotowych do dalszego wykorzystania w systemach biznesowych.

Jednym z najciekawszych elementów Document Intelligence jest możliwość tworzenia własnych, niestandardowych modeli (Custom Models). Dzięki nim możemy trenować usługę na przykładach dokumentów charakterystycznych dla naszej firmy, aby dokładnie rozpoznawała potrzebne pola. Model uczy się na podstawie oznaczonych przykładowych dokumentów i potrafi automatycznie wyciągać informacje, takie jak numer faktury, datę wystawienia, kwotę netto i brutto czy termin płatności.

Na potrzeby projektu stworzyłam model opierający się na fakturach z poniższego szablonu.

Przyjęłam, że wartości które będą istotne do analizy to numer faktury, dane osoby dla której faktura została wystawiona, data płatności, wartość podatku oraz pełna kwota faktury. W oparciu o te założenia przygotowałam własny model invoice-processor, w którym utworzyłam pola: InvoiceNumber, IssuedTo, DueDate, Tax oraz GrandTotal. Następnie oznaczyłam odpowiednie wartości w przykładowych dokumentach i wytrenowałam model, tak aby potrafił samodzielnie rozpoznawać je w nowych fakturach.

Do wytrenowania niestandardowego modelu w Azure Document Intelligence wymagane jest przygotowanie co najmniej 5 przykładowych dokumentów zawierających pola, które chcemy rozpoznawać. Microsoft zaleca jednak użycie 20–50 dokumentów, aby model mógł lepiej zrozumieć różne układy i warianty dokumentów. Zasada jest prosta – im większy i bardziej zróżnicowany zestaw treningowy, tym dokładniejsze i bardziej odporne na błędy będą wyniki analizy.

Sam proces opiera się na algorytmach uczenia maszynowego – model uczy się, jak rozpoznawać oznaczone przez nas pola, a następnie generalizuje tę wiedzę, aby radzić sobie z nowymi dokumentami o podobnej strukturze. Dzięki temu po wytrenowaniu jest w stanie automatycznie wyciągać wymagane informacje z faktur, nawet jeśli różnią się one wizualnie od przykładów użytych podczas treningu.

Warto wspomnieć, że usługa Azure Document Intelligence jest dostępna (choć z pewnymi ograniczeniami) również w ramach darmowego konta Azure. Dzięki temu, korzystając jedynie z konta deweloperskiego, mogłam zbudować rozwiązanie, które wykorzystuje zaawansowane procesy oparte na sztucznej inteligencji. To świetna opcja dla osób, które chcą przetestować możliwości narzędzia, stworzyć prototyp lub po prostu sprawdzić, jak automatyzacja obiegu dokumentów może usprawnić pracę w ich organizacji.

4. Szczegółowy przebieg Flow

Aby lepiej zrozumieć, jak działa całe rozwiązanie, warto przyjrzeć się procesowi krok po kroku.

1. Przepływ rozpoczyna akcja When Power Apps Calls a flow która przekazuje parametr File content - w tym przypadku plik przesłany przez użytkownika w aplikacji Power Apps.

   

2. Następną akcją jest Create file gdzie w bibliotece “DokumentyFaktur“ tworzony jest przesłany plik faktury.

   

   Wartość File Name została określona w wyrażeniu które generuje unikalną nazwę dla każdej faktury, w oparciu o datę i godzinę przesłania dokumentu.

    concat(
      'Invoice_', 
      formatDateTime(
        convertTimeZone(utcNow(), 'UTC', 'W. Europe Standard Time'), 
        'dd-MM-yyyy_HH_mm_ss'
      ), 
      '.pdf'
    )
   

3. Kolejnym krokiem jest akcja Get file properties która pobiera dane utworzonego pliku faktury, które będą nam potrzebne w kolejnym kroku.

   

4. Następnie w akcji Create item tworzymy nowy element listy “Faktury” z uwzględnieniem wartości takich jak “Title“ - odpowiadającego nazwie pliku bez rozszerzenia “.pdf“, “Status Value” ustawionym jako “New“ oraz “FileLink“ ustawionym jako adres do pliku faktury.

   

5. Kolejną akcją jest Analyze Document for Prebuilt or Custom models w której przekazywana jest między innymi nazwa modelu z którego chcemy korzystać przy analizie dokumentu. W tym przypadku wybrany został custom model invoice-processor, stworzony na potrzeby projektu. Kolejnym istotnym parametrem jest Document/Image File Content, który stanowi przesłany plik.

   

6. Po przeanalizowaniu dokumentu kolejnym etapem we flow jest Scope – Try, którego celem jest bezpieczne przetwarzanie wyników analizy i aktualizacja danych na liście SharePoint.

   

   Do jego elementów należą:

   • Akcja Compose która pobiera zwrócone Body po analizie dokumentu.

     

   • Akcja Parse JSON która służy do przetwarzania danych JSON i umożliwia łatwe wyciąganie poszczególnych wartości potrzebnych w kolejnych krokach.

     

   • Akcje Compose InvoiceNumber, Compose IssuedTo, Compose DueDate, ComposeTax, ComposeTotal, które pobierają poszczególne elementy ze zwróconej analizy dokumentu. Ułatwiają one dostęp do interesujących nas danych potrzebnych do aktualizacji elementu listy.

     Poniżej przykładowe wyrażenie pobierające wartość “InvoiceNumber“ z przeprowadzonej analizy.

     

   • Akcja Update Item w której aktualizujemy element listy o dane otrzymane z analizy pliku, z uwzględnieniem prawidłowego formatu.

7. Dodatkowo stworzony został Scope - Catch, który uruchamia się w przypadku niepowodzenia wykonania Scope - Try. Pełni on funkcję obsługi błędów.

   

Została w nim zawarta akcja Update item on Fail w której status elementu listy ustawiany jest na wartość “Error“.

5. Rezultaty

Nic nie oddaje działania aplikacji lepiej niż przykład w praktyce. Poniżej przedstawiam dwa scenariusze obrazujące rezultat całego procesu:

• poprawne dodanie faktury, które kończy się analizą dokumentu i uzupełnieniem danych w SharePoint,

  

• oraz sytuację, w której wystąpił błąd – a status faktury został automatycznie zmieniony na Error.

  

6. Podsumowanie

W tym artykule pokazałam, jak w pełni zautomatyzować proces obsługi faktur przy użyciu narzędzi z rodziny Microsoft. Udało się zbudować rozwiązanie, które automatycznie przetwarza faktury, zapisuje dane w SharePoint oraz obsługuje ewentualne błędy. Stworzenie takiego procesu nie wymaga dużego nakładu czasu ani zaawansowanej wiedzy programistycznej, a może znacząco usprawnić obieg dokumentów w firmie i pozwolić zespołowi skupić się na innych zadaniach, zyskując dodatkowe zasoby w codziennej pracy.

Projekt opisany we wpisie to aplikacja EventFlow, której celem jest kompleksowe zarządzanie wydarzeniami w organizacji.

1. Założenia projektu

Celem projektu jest stworzenie profesjonalnej aplikacji model-driven, która umożliwi pracownikom firmy:

• Zarządzanie wydarzeniami firmowymi (np. szkolenia, konferencje, integracje).

• Rejestrację uczestników i śledzenie frekwencji w odniesieniu do dostępnej liczby miejsc wydarzenia.

• Dodawanie anonimowych ocen po zakończeniu wydarzenia.

• Wizualizację danych dotyczących wydarzeń, uczestników i ocen w widokach tabel i dashboardach.

Tworząc aplikację należy pamiętać o następujących założeniach:

1. Uprawnienia użytkowników

   • Zwykły użytkownik może zapisać się na wydarzenie, dodać ocenę wydarzenia oraz przeglądać listę wydarzeń.

   • Tylko użytkownicy z rolą Organizatora mogą tworzyć i zarządzać wydarzeniami.

2. Daty wydarzenia

   • Wydarzenie nie może zostać utworzone z datą wsteczną.

   • Data zakończenia wydarzenia musi być późniejsza niż data jego rozpoczęcia.

3. Statusy wydarzeń

   • Każde wydarzenie może znajdować się w jednym z następujących statusów: “Planned”, “Registration”, “Full”, “In Progress”, “Completed”.

   • Status “Full” ustawiany jest automatycznie, gdy wydarzenie znajduje się w fazie “Registration” i liczba dostępnych miejsc wynosi 0.

   • Status “In Progress” ustawiany jest automatycznie, gdy bieżąca data mieści się w przedziale między datą rozpoczęcia a datą zakończenia wydarzenia.

   • Status “Completed” ustawiany jest automatycznie po upływie daty i godziny zakończenia wydarzenia.

4. Dostępność miejsc wydarzenia

   • Każde wydarzenie ma określoną maksymalną liczbę miejsc.

   • Liczba dostępnych miejsc wyliczana jest automatycznie na podstawie całkowitej pojemności oraz liczby zapisanych uczestników.

   • Użytkownik może zapisać się tylko na wydarzenie w statusie “Registration” i jedynie wtedy, gdy liczba dostępnych miejsc jest większa od zera.

5. Oceny wydarzeń

   • Dodanie oceny do wydarzenia możliwe jest wyłącznie po jego zakończeniu (status “Completed”).

2. Tabele i relacje

Sercem każdej aplikacji model-driven są dane przechowywane w Dataverse. Dataverse to nowoczesna platforma do przechowywania danych w chmurze Microsoft, która umożliwia tworzenie tabel, definiowanie atrybutów, relacji oraz logiki biznesowej. Aplikacje model-driven mogą w prosty sposób korzystać z tych danych, prezentować je w widokach, formularzach i dashboardach oraz integrować z innymi aplikacjami i usługami w ekosystemie Microsoft Power Platform.

2.1. Tabela Event

Ta tabela zawiera wszystkie informacje dotyczące wydarzeń w firmie. Zawiera kolumny takie jak:

• Event Indicator - (Text) Primary Name Column, nazwa wydarzenia + data, rekord służący do wyszukiwania wydarzenia w Lookupach (wymagane)

• Event Name - (Text) nazwa wydarzenia (wymagane)

• Start Date - (Date and time) początek wydarzenia (wymagane)

• End Date - (Date and time) koniec wydarzenia (wymagane)

• Capacity - (Whole number) maksymalna liczba uczestników wydarzenia (wymagane)

• Event Status - (Choice) status wydarzenia: “Planned“, “Registration“, “Full“, “In Progress“, “Completed“ (wymagane)

• Organizer - (Lookup do systemowej tabeli Contact) osoba organizująca wydarzenie (wymagane)

• Available Seats - (Whole number - Calculated: Capacity - Number of Participants) dostępna liczba miejsc do zapisania

• Average Rating - (Decimal - Rollup: średnia Feedback.Rating dla powiązanych rekordów tabeli Event) średnia ocen

• Number Of Participants - (Whole number - Rollup: Policz powiązane rekordy z tabeli Participant gdzie Registration Status ≠ Cancelled) liczba zapisanych uczestników

• Number Of Responses - (Whole number - Rollup: Policz powiązane rekordy z tabeli Feedback) liczba wystawionych ocen

2.2. Tabela Participant

Ta tabela zawiera wszystkie informacje na temat uczestników wydarzeń. Zawiera kolumny takie jak:

• First Name - (Text) imię uczestnika (wymagane)

• Last Name - (Text) nazwisko uczestnika (wymagane)

• Email - (Email) adres email uczestnika (wymagane)

• Phone - (Phone number) telefon kontaktowy uczestnika (wymagane)

• Registration Status - (Choice) status deklaracji uczestnictwa: “Registered“, “Confirmed“, “Canceled“ (wymagane)

• Event - (Lookup do tabeli Event) wydarzenie na które zapisuje się uczestnik (wymagane)

2.3. Tabela Feedback

Ta tabela zawiera wszystkie informacje na temat anonimowych ocen wydarzeń. Zawiera kolumny takie jak:

• Rating - (Whole number) ocena wydarzenia od 1 do 5 (wymagane)

• Comment - (Text) komentarz do oceny (opcjonalne)

• Event - (Lookup do tabeli Event) oceniane wydarzenie (wymagane)

2.4. Relacje między tabelami

Tabele w aplikacji są ze sobą ściśle powiązane, co umożliwia tworzenie spójnego modelu danych:

• Event (1:N) Participant – jedno wydarzenie może mieć wielu uczestników, uczestnik należy zawsze do jednego wydarzenia.

• Event (1:N) Feedback – jedno wydarzenie może mieć wiele ocen, ocena zawsze przypisana jest do jednego wydarzenia.

Dzięki temu model danych jest prosty, a jednocześnie pozwala na:

• monitorowanie frekwencji,

• kontrolę dostępnych miejsc,

• analizę ocen i rankingów wydarzeń.

3. Widoki

W aplikacjach model-driven bardzo ważnym elementem są widoki (Views), które pozwalają użytkownikowi szybko przeglądać i analizować dane. W projekcie EventFlow przygotowałam zestaw widoków dla każdej z tabel.

3.1. Widoki tabeli Event

• Upcoming Events – prezentuje nadchodzące wydarzenia, które mają status Planned, Registration lub Full sortowane po dacie rozpoczęcia wydarzenia rosnąco.

  

• Completed Events – pokazuje tylko zakończone wydarzenia, które mają status Completed. Widok posortowany jest według daty zakończenia malejąco.

  

• Events In Progress - pokazuje tylko te wydarzenia, które mają status In Progress.

  

• Events - All – pełny katalog wszystkich wydarzeń, który jest domyślnym widokiem tabeli Event.

  

3.2. Widoki tabeli Participant

• Participants – Active – pokazuje wszystkich uczestników z aktywnym statusem rejestracji (Registered, Confirmed).

  

• Participants - All – pełny katalog wszystkich uczestników, niezależnie od statusu rejestracji. Domyślny widok dla tabeli Participant.

  

3.3. Widoki tabeli Feedback

• Feedback – All – lista wszystkich ocen wystawionych w aplikacji. Domyślny widok dla tabeli Feedback.

  

• Feedback – By Event – widok pogrupowany według wydarzeń, co umożliwia szybkie porównanie ocen między poszczególnymi szkoleniami.

  

4. Formularze

Formularze w aplikacji model-driven pełnią kluczową rolę w pracy użytkowników – to właśnie one stanowią główny interfejs do wprowadzania, przeglądania i edycji danych zapisanych w tabelach Dataverse. Odpowiednio zaprojektowany formularz nie tylko pozwala na wprowadzanie i aktualizację rekordów, ale także prowadzi użytkownika przez proces biznesowy, ukrywając pola zbędne w danym kontekście i eksponując te, które są najważniejsze. Dzięki zakładkom, sekcjom, subgridom i regułom widoczności możliwe jest stworzenie interfejsu czytelnego, intuicyjnego i zgodnego z logiką aplikacji.

4.1. Formularz tabeli Event

Formularz podzielono na 4 sekcje:

• Event Details - zawiera podstawowe informacje dotyczące wydarzenia: Event Name, Organizer, Start Date, End Date, Capacity, Event Status.

  

• Metrics - zawiera kluczowe wskaźniki liczbowe: Number Of Participants, Available Seats, Average Rating

  

• Participants - subgrid wskazujący uczestników przypisanych do danego wydarzenia ze statusem uczestnictwa innym niż “Cancelled”. Formularz zawiera funkcję “Add New” umożliwiającą na szybkie stworzenie nowego rekordu uczestnika dla wybranego wydarzenia.

  

• Feedback - subgrid wskazujący na oceny powiązane z wydarzeniem. Formularz zawiera funkcję “Add New” umożliwiającą na szybkie stworzenie nowego rekordu oceny dla wybranego wydarzenia.

  

Logika widoczności danych pól i sekcji w formularzu została zaimplementowana w skrypcie eventForm.js który został dodany jako Web resource.

Biorąc pod uwagę, że sekcja Metrics zawiera jedynie pola obliczeniowe, nie jest ona widoczna w momencie tworzenia nowego rekordu. Logika ta została zaimplementowana w funkcji setMetricsSectionVisibility(), gdzie sprawdzany jest typ formularza (wartość 1 wskazuje na formularz tworzenia rekordu) i na jego podstawie ustawiana jest widoczność sekcji. Funkcja ta została podpięta do zdarzenia OnLoad formularza.

function setMetricsSectionVisibility(executionContext) {
  const formContext = executionContext.getFormContext();
  const formType = formContext.ui.getFormType();

  const metricsSection = formContext.ui.tabs
    .get("General")
    .sections.get("metrics_section");

  if (metricsSection) {
    if (formType === 1) {
      metricsSection.setVisible(false);
    } else {
      metricsSection.setVisible(true);
    }
  }
}

Dodatkowo dodana została funkcja setAvaliableSeatsVisibility(), odpowiadająca za widoczność pola Available Seats. Sprawdzany jest typ formularza (czy jest to formularz edycji rekordu lub read-only) a następnie status wydarzenia. Biorąc pod uwagę nieistotność wartości odpowiadającej za dostępność miejsc dla wydarzenia które jest już zakończone, wartość ta jest ukrywana gdy status wydarzenia jest “Completed”.

function setAvaliableSeatsVisibility(executionContext) {
  const formContext = executionContext.getFormContext();
  const formType = formContext.ui.getFormType();

  if (formType === 2 || formType === 3) {
    const availableSeats = formContext.getControl("kr_availableseats");
    const eventStatus = formContext.getAttribute("kr_eventstatus").getValue();

    if (availableSeats && eventStatus) {
      if (eventStatus !== 124070004) {
        availableSeats.setVisible(true);
      } else {
        availableSeats.setVisible(false);
      }
    }
  }
}

Kolejnym polem obliczeniowym sekcji Metrics, którego widoczność została uwarunkowana w skrypcie, jest pole AverageRating. Biorąc pod uwagę, że użytkownik nie może dodać oceny do wydarzenia którego status jest inny niż “Completed“ pole to jest ukrywane do momentu aż wydarzenie osiągnie wspomniany status.

function setAverageRatingVisibility(executionContext) {
  const formContext = executionContext.getFormContext();
  const formType = formContext.ui.getFormType();

  if (formType === 2 || formType === 3) {
    const averageRating = formContext.getControl("kr_averagerating");
    const eventStatus = formContext.getAttribute("kr_eventstatus").getValue();

    if (averageRating && eventStatus) {
      if (eventStatus === 124070004) {
        averageRating.setVisible(true);
      } else {
        averageRating.setVisible(false);
      }
    }
  }
}

Jeżeli chodzi o widoczność sekcji Participants, zastosowano bliźniaczą logikę jak w przypadku sekcji Metrics.

function setparticipantsSectionVisibility(executionContext) {
  const formContext = executionContext.getFormContext();
  const formType = formContext.ui.getFormType();

  const participantsSection = formContext.ui.tabs
    .get("General")
    .sections.get("participants_section");

  if (participantsSection) {
    if (formType === 1) {
      participantsSection.setVisible(false);
    } else {
      participantsSection.setVisible(true);
    }
  }
}

Nieco inne podejście zastosowano przy widoczności sekcji Feedback. Sprawdzany jest typ formularza (czy jest to formularz edycji rekordu lub read-only) oraz status wydarzenia. Sekcja ta jest widoczna jedynie przy statusie wydarzenia “Completed“ - biorąc pod uwagę fakt, że użytkownik nie może dodawać oceny do wydarzenia z innym statusem.

function setFeedbackSectionVisibility(executionContext) {
  const formContext = executionContext.getFormContext();
  const formType = formContext.ui.getFormType();

  const feedbackSection = formContext.ui.tabs
    .get("General")
    .sections.get("feedback_section");

  if (formType === 2 || formType === 3) {
    const eventStatus = formContext.getAttribute("kr_eventstatus").getValue();
    if (eventStatus === 124070004) {
      feedbackSection.setVisible(true);
    } else {
      feedbackSection.setVisible(false);
    }
  } else {
    feedbackSection.setVisible(false);
  }
}

4.2. Formularz Tabeli Participants

Formularz podzielono na 2 sekcje:

• Participant Details - zawiera podstawowe dane osobowe uczestnika oraz status uczestnictwa: First Name, Last Name, Email, Phone, Registration Status

• Event Info - zawiera informacje o wydarzeniu w którym użytkownik chce uczestniczyć: Event

  

4.3. Formularz Tabeli Feedback

Formularz podzielono na 2 sekcje:

• Feedback Details - zawiera ocenę wydarzenia oraz opcjonalny komentarz: Rating, Comment

• Event Info - zawiera informacje o wydarzeniu którego dotyczy ocena: Event

  

5. Walidacja formularzy

Walidacja formularzy w aplikacjach model-driven jest kluczowa, aby zapewnić spójność i poprawność danych wprowadzanych przez użytkowników. W projekcie EventFlow logika walidacyjna została zrealizowana głównie z wykorzystaniem skryptów JavaScript, które pozwalają na implementację niestandardowych reguł biznesowych. Dodatkowo, w celu zaprezentowania możliwości konfiguracji wizualnej, w aplikacji została zaimplementowana jedna reguła biznesowa (Business Rule).

5.1. Walidacja formularza tabeli Event

Walidacja w formularzu wydarzeń polega głównie na walidacji daty. Należało pamiętać o kilku zasadach. Między innymi o uniemożliwieniu użytkownikowi wprowadzenia daty zakończenia wydarzenia późniejszej niż daty rozpoczęcia. Walidacja ta została zaimplementowana za pomocą Business Rule w tabeli Event.

Kolejną zasadą jest uniemożliwienie użytkownikowi dodania wydarzenia z datą wsteczną. Walidacja ta została zaimplementowana w funkcji validateEventDate() w skrypcie eventForm.js. Funkcja ta została podpięta do zdarzenia OnChange wartości Start Date.

function validateEventDate(executionContext) {
  const formContext = executionContext.getFormContext();

  const startDateValue = formContext.getAttribute("kr_startdate").getValue();
  const startDateCtrl = formContext.getControl("kr_startdate");


  if(startDateValue &&startDateCtrl ) {
    const now = new Date();

    if(startDateValue < now) {
      startDateCtrl.setNotification("Start Date cannot be in the past.", "startDateError");
    } else {
      startDateCtrl.clearNotification("startDateError");
    }
  }
}

Dodatkowo zaimplementowana została funkcja setEndDateSugestion() która ustawia datę zakończenia wydarzenia na datę początkową, po wybraniu wartości Star Date. Z reguły wydarzenia kończą się tego samego dnia, dzięki temu wybór zakończenia wydarzenia najprawdopodobniej ograniczy się do ustawiania odpowiedniej godziny zakończenia. Funkcja ta została podpięta do zdarzenia OnChange wartości StartDate.

function setEndDateSuggestion(executionContext) {
  const formContext = executionContext.getFormContext();

  const startDate = formContext.getAttribute("kr_startdate").getValue();
  const endDate = formContext.getAttribute("kr_enddate");

  if (startDate && endDate) {
    endDate.setValue(startDate);
    endDate.setSubmitMode("always");
  }
}

5.2. Walidacja formularza tabeli Participant

Walidacja formularza tabeli Participant została zaimplementowana w skrypcie participantForm.js który został dodany jako jeden z Web resource projektu.

Funkcja validatePhoneNumber() sprawdza czy wprowadzony numer telefonu użytkownika ma poprawny format (zgodny z zasadami polskich numerów telefonów). Funkcja ta została dodana do zdarzenia OnChange pola Phone oraz OnSave formularza.

function validatePhoneNumber(executionContext) {
  const formContext = executionContext.getFormContext();
  const phoneAttr = formContext.getAttribute("kr_phone");
  const ctrl = formContext.getControl("kr_phone");

  if (!phoneAttr || !ctrl) return;

  const phoneValue = phoneAttr.getValue();

  const phoneRegex = /^(?:\+48|0048)?[\s-]?\d{3}[\s-]?\d{3}[\s-]?\d{3}$/;

  if (phoneValue && !phoneRegex.test(phoneValue)) {
    ctrl.setNotification("Wrong phone number.", "phoneError");
  } else {
    ctrl.clearNotification("phoneError");
  }
}

Oprócz tego, w skrypcie zaimplementowano funkcje setLookupFilter() oraz validateEventOnSave().

Funkcja setLookupFilter() ogranicza listę wydarzeń widocznych w polu Event tylko do tych, które mają status “Registration” oraz posiadają wolne miejsca (Available Seats ≠ 0). Funkcja ta jest podłączona do zdarzenia OnLoad formularza.

function setEventLookupFilter(executionContext) {
  const formContext = executionContext.getFormContext();

  const eventLookupAttr = formContext.getAttribute("kr_event");
  const eventLookupCtrl = formContext.getControl("kr_event");

  if (eventLookupAttr && eventLookupCtrl) {
    const registrationEventStatus = 124070001;

    eventLookupCtrl.addPreSearch(function () {
      const filter = `
                <filter type="and">
                    <condition attribute="kr_eventstatus" operator="eq" value="${registrationEventStatus}" />
                    <condition attribute="kr_availableseats" operator="neq" value="0" />
                </filter>
            `;

      eventLookupCtrl.addCustomFilter(filter);
    });
  }
}

Z kolei validateEventOnSave() działa podczas zapisywania formularza (zdarzenie OnSave) uczestnika i sprawdza, czy wybrane wydarzenie spełnia warunki rejestracji. Weryfikuje ona, czy status wydarzenia to “Registration” oraz czy istnieją wolne miejsca. Jeśli którykolwiek z warunków nie jest spełniony, zapis zostaje zablokowany, a użytkownik otrzymuje komunikat ostrzegawczy. Ze względu na ograniczenia planu Developer, który nie obsługuje wywołań asynchronicznych, implementacja musiała zostać wykonana w trybie synchronicznym.

Funkcja ta została zaimplementowana, ponieważ użytkownik ma możliwość dodania uczestnika bezpośrednio z poziomu widoku wydarzenia. W takiej sytuacji istnieje ryzyko, że uczestnik zostanie przypisany do wydarzenia niespełniającego założonych warunków (np. o statusie innym niż “Registration” lub z brakiem dostępnych miejsc). Funkcja ta pełni rolę mechanizmu zabezpieczającego – wymusza ponowną weryfikację stanu wydarzenia w momencie zapisu i zapobiega wprowadzeniu niepoprawnych danych do systemu.

function validateEventOnSave(executionContext) {
  const formContext = executionContext.getFormContext();
  const selectedEvent = formContext.getAttribute("kr_event").getValue();

  if (!selectedEvent) return;

  const eventId = selectedEvent[0].id.replace(/[{}]/g, "");
  const req = new XMLHttpRequest();
  req.open("GET", Xrm.Utility.getGlobalContext().getClientUrl() + 
    `/api/data/v9.2/kr_events(${eventId})?$select=kr_eventstatus,kr_availableseats`, false);
  req.setRequestHeader("OData-MaxVersion", "4.0");
  req.setRequestHeader("OData-Version", "4.0");
  req.setRequestHeader("Accept", "application/json");
  req.setRequestHeader("Content-Type", "application/json; charset=utf-8");

  req.send();

  if (req.status === 200) {
    const eventRecord = JSON.parse(req.responseText);
    const eventStatus = eventRecord["kr_eventstatus"];
    const availableSeats = eventRecord["kr_availableseats"];

    if (eventStatus !== 124070001 || availableSeats === 0) {
      executionContext.getEventArgs().preventDefault();
      Xrm.Navigation.openAlertDialog({
        text: "Cannot register - the event is not in Registration status or there are no available seats."
      });
    }
  } else {
    console.error("Error fetching event:", req.statusText);
    executionContext.getEventArgs().preventDefault();
  }
}

5.3. Walidacja formularza tabeli Feedback

Walidacja formularza tabeli Feedback została zaimplementowana w skrypcie feedbackForm.js, dodanym jako zasób typu Web Resource. Podobnie jak w przypadku formularza Participants, konieczne było ograniczenie listy dostępnych wydarzeń w polu Event tak, aby użytkownik mógł powiązać ocenę wyłącznie z poprawnym rekordem. Zgodnie z założeniami, oceny mogą być dodawane tylko do wydarzeń o statusie „Completed”.

Logika ta została zaimplementowana w funkcji setEventLookupFilter(), wywoływanej podczas zdarzenia OnLoad formularza. Funkcja dynamicznie filtruje zawartość pola lookup i udostępnia użytkownikowi jedynie wydarzenia zakończone.

function setEventLookupFilter(executionContext) {
  const formContext = executionContext.getFormContext();

  const eventLookupAttr = formContext.getAttribute("kr_event");
  const eventLookupCtrl = formContext.getControl("kr_event");

  if (eventLookupAttr && eventLookupCtrl) {
    const completeEventStatus = 124070004;

    eventLookupCtrl.addPreSearch(function () {
      const filter = `
                <filter type="and">
                    <condition attribute="kr_eventstatus" operator="eq" value="${completeEventStatus}" />
                </filter>
            `;

      eventLookupCtrl.addCustomFilter(filter);
    });
  }
}

Warto zauważyć, że w tym przypadku nie ma konieczności dodawania dodatkowych mechanizmów zabezpieczających (tak jak w tabeli Participants). Wynika to z faktu, iż subgrid tabeli Feedback na formularzu Event jest widoczny wyłącznie wtedy, gdy wydarzenie posiada status „Completed”. Tym samym sama logika aplikacji uniemożliwia dodanie niepoprawnego wpisu.

6. Tworzenie wartości Event Indicator (Primary Name Column dla tabeli Event)

W każdej tabeli w Dataverse istnieje jedno pole oznaczone jako Primary Name Column. Jest to kolumna główna, której wartości służą m.in do identyfikowania rekordów w interfejsie użytkownika (np. w polach typu lookup).

W tabeli Event funkcję tę pełni pole Event Indicator. Funkcja setEventIndicator() została stworzona w celu automatycznego generowania spójnej wartości dla tego pola, bez konieczności ingerencji użytkownika. Dzięki temu wartość jest łatwa do zidentyfikowania podczas dodawania oceny lub rejestracji uczestnika na wydarzenie. Sama nazwa wydarzenia może być niewystarczająca, ponieważ istnieje prawdopodobieństwo, że w dłuższej perspektywie czasu powstaną dwa wydarzenia o takiej samej nazwie (np. cykliczne szkolenia lub warsztaty).

Z tego powodu pole Event Indicator budowane jest w oparciu o dwie wartości: Event Name oraz Start Date. Dzięki temu każdemu rekordowi przypisany zostaje jednoznaczny identyfikator (np. Warsztaty CRM 15-03-2025), co ułatwia rozróżnianie poszczególnych wydarzeń.

function setEventIndicator(executionContext) {
  const formContext = executionContext.getFormContext();

  const eventName = formContext.getAttribute("kr_eventname").getValue();
  const startDate = formContext.getAttribute("kr_startdate").getValue();

  if (eventName && startDate) {
    const day = String(startDate.getDate()).padStart(2, "0");
    const month = String(startDate.getMonth() + 1).padStart(2, "0");
    const year = startDate.getFullYear();

    formContext
      .getAttribute("kr_eventnumber")
      .setValue(eventName + " " + `${day}-${month}-${year}`);
    formContext.getAttribute("kr_eventnumber").setSubmitMode("always");
  }
}

Funkcja została powiązana ze zdarzeniem OnSave formularza, dzięki czemu wartość pola Event Indicator generowana jest automatycznie w momencie zapisywania rekordu do bazy danych.

7. Zarządzanie statusami wydarzenia

Azure Functions to środowisko uruchomieniowe w chmurze Microsoftu, które pozwala uruchamiać małe fragmenty kodu w odpowiedzi na różne zdarzenia, takie jak HTTP requesty, zdarzenia w kolejce, zmiany w bazie danych czy wyzwalacze czasowe.

W projekcie przewidziano funkcję automatycznego ustawiania statusów wydarzeń, która ułatwia monitorowanie cyklu życia każdego eventu. Na potrzeby naszego projektu została zaimplementowana funkcja Azure UpdateEventTableStatuses.

const tokenEndpoint = (tenantId) =>
  `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`;

async function getAccessToken({ tenantId, clientId, clientSecret, dataverseUrl }) {
  const body = new URLSearchParams({
    client_id: clientId,
    client_secret: clientSecret,
    scope: `${dataverseUrl}/.default`,
    grant_type: "client_credentials",
  });

  const res = await fetch(tokenEndpoint(tenantId), {
    method: "POST",
    headers: { "Content-Type": "application/x-www-form-urlencoded" },
    body,
  });

  if (!res.ok) throw new Error(await res.text());
  const data = await res.json();
  return data.access_token;
}

async function getRecords({ dataverseUrl, table, token }) {
  const res = await fetch(`${dataverseUrl}/api/data/v9.2/${table}?$select=kr_startdate,kr_enddate,kr_eventstatus,kr_availableseats`, {
    headers: {
      Authorization: `Bearer ${token}`,
      Accept: "application/json",
    },
  });
  if (!res.ok) throw new Error(await res.text());
  const data = await res.json();
  return data.value;
}

async function updateRecord({ dataverseUrl, table, id, body, token }) {
  const res = await fetch(`${dataverseUrl}/api/data/v9.2/${table}(${id})`, {
    method: "PATCH",
    headers: {
      Authorization: `Bearer ${token}`,
      "Content-Type": "application/json",
      Accept: "application/json",
      "If-Match": "*",
    },
    body: JSON.stringify(body),
  });
  if (!res.ok) throw new Error(await res.text());
}

function computeEventStatus(record) {
  const statuses = {
    registration: 124070001,
    full: 124070005,
    inProgress: 124070003,
    complete: 124070004,
  };

  const startDate = record.kr_startdate ? new Date(record.kr_startdate) : null;
  const endDate = record.kr_enddate ? new Date(record.kr_enddate) : null;
  const currentStatus = record.kr_eventstatus;
  const availableSeats = record.kr_availableseats;
  const now = new Date();

  if (!startDate || !endDate) return null;

  if (currentStatus === statuses.registration && availableSeats === 0) {
    return statuses.full;
  } else if (startDate <= now && endDate >= now) {
    return statuses.inProgress;
  } else if (endDate < now) {
    return statuses.complete;
  }
  return null;
}

module.exports = async function (context, myTimer) {
  const tenantId = process.env.TENANT_ID;
  const clientId = process.env.CLIENT_ID;
  const clientSecret = process.env.CLIENT_SECRET;
  const dataverseUrl = process.env.DATAVERSE_URL;
  const table = process.env.TABLE_LOGICAL_NAME;
  const pk = process.env.PRIMARY_KEY_LOGICAL_NAME;

  const token = await getAccessToken({ tenantId, clientId, clientSecret, dataverseUrl });
  const records = await getRecords({ dataverseUrl, table, token });

  for (let r of records) {
    cosnt newStatus = computeEventStatus(r);
    if (newStatus && newStatus !== r.kr_eventstatus) {
      await updateRecord({ dataverseUrl, table, id: r[pk], body: { kr_eventstatus: newStatus }, token });
    }
  }
};

Jak działa nasze rozwiązanie:

1. Pobranie danych uwierzytelniających
   Funkcja najpierw odczytuje z ustawień aplikacji wartości niezbędne do połączenia z Dataverse: tenant ID, client ID i client secret, URL środowiska Dataverse, nazwę tabeli oraz jej klucz główny.

2. Pozyskanie tokenu dostępu
   Na podstawie tych danych funkcja wykonuje żądanie do Azure AD w celu uzyskania tokenu OAuth2. Token pozwala funkcji na autoryzowany dostęp do Dataverse i wykonywanie operacji na danych bez udziału użytkownika.

3. Pobranie rekordów z tabeli wydarzeń
   Po uzyskaniu tokenu funkcja pobiera wszystkie rekordy z tabeli wydarzeń, wybierając tylko kluczowe pola: daty rozpoczęcia i zakończenia, aktualny status wydarzenia oraz liczbę dostępnych miejsc.

4. Tworzenie nowego statusu wydarzenia
   Dla każdego rekordu funkcja analizuje jego dane i decyduje o odpowiednim statusie:

   • jeśli wydarzenie jest w fazie rejestracji i nie ma już wolnych miejsc - status zmienia się na „Full”,

   • jeśli obecna pora jest pomiędzy rozpoczęciem a zakończeniem wydarzenia- status zmienia się na „In Progress”,

   • jeśli obecna pora jest późniejsza niż zakończenie wydarzenia - status zmienia się na „Completed”.

5. Aktualizacja rekordów w Dataverse
   Jeśli nowy status różni się od obecnego, funkcja wysyła żądanie aktualizacji do Dataverse, zmieniając status wydarzenia w tabeli.

6. Automatyczne wywołanie co określony czas
   Funkcja jest wyzwalana przez mechanizm Timer Trigger w Azure Functions. Dzięki temu proces aktualizacji statusów odbywa się automatycznie co 30 minut, bez potrzeby ręcznego uruchamiania lub monitorowania.

7. Bezpieczeństwo i uprawnienia
   Funkcja korzysta z Application User w Dataverse, któremu przypisano rolę Organizer umożliwiającą na odczyt i manipulację rekordów w tabeli Event. Dzięki temu operacje wykonywane przez funkcję są w pełni bezpieczne i zgodne z zasadami uprawnień w Dataverse.

W naszym projekcie Azure Function okazała się idealnym rozwiązaniem do automatycznego ustawiania statusów wydarzeń w Dataverse. Funkcjonalność ta pozwoliła nam obejść ograniczenia konta developer, które nie daje dostępu do premium connectorów w Power Automate.

8. Wykresy i dashboardy

W aplikacjach model-driven wykresy i dashboardy pełnią kluczową rolę w prezentacji danych w sposób wizualny i przystępny. Dzięki nim użytkownicy mogą szybko analizować informacje, wyciągać wnioski i podejmować decyzje bez konieczności przeglądania długich list rekordów.

• Wykresy (Charts) – to wizualizacje oparte na danych z tabel, które pozwalają przedstawić trendy, porównania czy rankingi. Mogą być wyświetlane samodzielnie lub jako część formularza czy dashboardu.

• Dashboardy – to zbiory widoków, wykresów i list, które w jednym miejscu dostarczają użytkownikowi całościowego obrazu sytuacji biznesowej. Dzięki nim możliwe jest monitorowanie kluczowych wskaźników w czasie rzeczywistym.

W projekcie EventFlow przygotowano główny dashboard, którego celem jest dostarczenie organizatorom i uczestnikom szybkiego wglądu w najważniejsze informacje o wydarzeniach:

• Wykres 1 – Top Rated Events - Ranking pięciu najlepiej ocenianych wydarzeń. Dzięki niemu można szybko sprawdzić, które szkolenia czy konferencje były najlepiej odbierane przez uczestników.

• Widok Upcoming Events - Lista wszystkich zaplanowanych wydarzeń, które jeszcze się nie rozpoczęły. Widok ten umożliwia szybkie sprawdzenie harmonogramu i dostępności miejsc.

• Wykres 2 – Attendance - Ranking pięciu wydarzeń z największą frekwencją. Wykres ten pozwala ocenić, które wydarzenia cieszyły się największym zainteresowaniem.

9. Business Process Flow

Business Process Flow w aplikacjach model-driven to mechanizm pozwalający definiować i wizualizować kolejne etapy procesu biznesowego, które użytkownik powinien wykonać podczas pracy z rekordem. BPF prowadzi użytkownika krok po kroku, podpowiadając wymagane pola i działania na każdym etapie, a także zapewnia spójność danych i ułatwia ich kompletność.

W aplikacji EventFlow zdefiniowano Business Process Flow o nazwie Event Lifecycle Process, który odzwierciedla cykl życia wydarzenia i prowadzi użytkownika przez kolejne etapy.

1. Planning – pierwszy etap, w którym użytkownik wprowadza podstawowe informacje o wydarzeniu. Wymagane pola to: Event Name, Start Date, End Date, Capacity oraz Organizer.

2. Event Preparation – etap przygotowania wydarzenia, w którym należy określić status wydarzenia.

3. Post-Event Evaluation – etap końcowy, odpowiadający zakończeniu wydarzenia i możliwości jego oceny. Do jego zamknięcia konieczne jest aby rekord posiadał wartości w polach: Average Rating oraz Number Of Responses, co umożliwia pełną ocenę i analizę wydarzenia.

Event Lifecycle Process wspiera użytkowników w uporządkowany sposób, od planowania po ocenę wydarzenia, odzwierciedlając rzeczywiste etapy cyklu życia wydarzenia.

10. Site Map

W aplikacjach model-driven nawigacja opiera się na tzw. Site Map – jest to mapa witryny, która określa, jakie obszary i grupy funkcjonalne widzi użytkownik w menu aplikacji. Site Map pozwala uporządkować tabele, formularze, dashboardy i raporty w logiczne sekcje, ułatwiając dostęp do danych i funkcji.

W projekcie EventFlow nawigacja została podzielona na dwa główne obszary:

• Event Management → Insights
  Udostępnia dashboard Events Overview, który wizualizuje dane o wydarzeniach, uczestnikach i ocenach, wspierając analizę i monitorowanie wydarzeń.

• Event Management → Operations
  Zawiera dostęp do głównych tabel: Event, Participant i Feedback, umożliwiając zarządzanie wydarzeniami, rejestrację uczestników oraz przegląd anonimowych ocen.

Takie rozdzielenie funkcji pozwala użytkownikom szybko odnaleźć potrzebne informacje i wykonywać zadania zgodnie z ich rolą w firmie.

11. Uprawnienia użytkowników

W aplikacji EventFlow wyróżniono dwie główne role systemowe:

• Participant / Evaluator – rola przeznaczona dla pracowników biorących udział w wydarzeniach i wystawiających oceny.

• Organizer – rola dla osób odpowiedzialnych za organizację wydarzeń i zarządzanie uczestnikami.

Podział ról został zaprojektowany w taki sposób, aby każdy użytkownik posiadał wyłącznie niezbędne uprawnienia, a jednocześnie dane w systemie były w pełni bezpieczne.

11.1. Rola Participant / Evaluator

Rola ta skupia się na użytkownikach końcowych, którzy korzystają z aplikacji w celu uczestniczenia w wydarzeniach oraz oceniania ich po zakończeniu.

• Tabela Event:

  • Read (Organization) – dostęp tylko do odczytu wszystkich wydarzeń.

  • Brak możliwości tworzenia, edycji czy usuwania wydarzeń.

  • Append/Append To (Organization) – na potrzeby relacji lookup.

• Tabela Participant:

  • Create (User) – użytkownik może zapisać się na wydarzenie.

  • Read (Organization) – dostęp do listy uczestników wydarzenia.

  • Write (User) – możliwość edycji własnej rejestracji (np. zmiana statusu na “Cancelled”).

• Tabela Feedback:

  • Create (User) – możliwość dodania oceny i komentarza do wydarzenia.

  • Read (Organization) – możliwość przeglądania ocen powiązanych z wydarzeniem.

  • Write (User) – edycja własnych ocen.

• Tabela Contact:

  • Read (Organization) – wgląd w podstawowe dane kontaktowe organizatora (Lookup).

  • Append/Append To (Organization) – na potrzeby relacji lookup.

11.2. Rola Organizer

Rola ta została zaprojektowana dla osób zarządzających wydarzeniami. Obejmuje szersze uprawnienia, które umożliwiają pełną kontrolę nad procesem planowania, organizacji i ewaluacji.

• Tabela Event:

  • Create (Organization) – możliwość tworzenia nowych wydarzeń.

  • Read (Organization) – pełny wgląd we wszystkie wydarzenia.

  • Write (Organization) – edycja wszystkich wydarzeń.

  • Delete (Organization) – możliwość usuwania wszystkich wydarzeń.

  • Append/Append To (Organization) – na potrzeby relacji lookup.

• Tabela Participant:

  • Create (Organization) – możliwość dodania uczestnika do wydarzenia.

  • Read (Organization) – pełny dostęp do listy uczestników.

  • Write (Organization) – edycja dowolnych rekordów uczestników (np. potwierdzanie uczestnictwa).

  • Delete (Organization) – możliwość usuwania wszystkich rekordów uczestników.

• Tabela Feedback:

  • Read (Organization) – dostęp do wszystkich ocen.

  • Brak możliwości usuwania i edycji rekordów.

• Tabela Contact:

  • Read (Organization) – dostęp do pełnej listy kontaktów.

  • Append/Append To (Organization) – na potrzeby relacji lookup.

12. Wnioski i podsumowanie

Projekt EventFlow pokazał, że aplikacje model-driven w Microsoft Power Platform pozwalają w szybki i prosty sposób tworzyć kompleksowe rozwiązania biznesowe oparte na danych z Dataverse.

W trakcie realizacji projektu udało się między innymi:

• Zaprojektować struktury danych aplikacji.

• Stworzyć formularze z logiką walidacji i regułami widoczności pól oraz sekcji.

• Zaimplementować automatyzację statusów wydarzeń w oparciu o daty i liczbę dostępnych miejsc.

• Skonfigurować role i uprawnienia użytkowników.

• Utworzyć dashboardy, wykresy i widoki umożliwiające szybki wgląd w najważniejsze wskaźniki wydarzeń.

Podsumowując, EventFlow stanowi przykład profesjonalnej aplikacji biznesowej typu model-driven, która łączy intuicyjny interfejs z wydajną logiką biznesową i umożliwia kompleksowe zarządzanie wydarzeniami w firmie. Pomimo pewnych ograniczeń środowiska deweloperskiego, aplikacja w pełni spełnia założenia projektowe i może być w prosty sposób rozszerzana w przyszłości.

1. Założenia projektu

Celem projektu jest stworzenie profesjonalnej aplikacji biznesowej, która umożliwi pracownikom firmy łatwe i bezproblemowe rezerwowanie dostępnych sal konferencyjnych. Aplikacja powinna łączyć intuicyjny interfejs z wydajną logiką biznesową oraz zapewniać pełną kontrolę nad danymi w backendzie.

Użytkownicy aplikacji powinni mieć możliwość:

• Przeglądania listy dostępnych sal konferencyjnych wraz z ich opisem, lokalizacją, wyposażeniem i aktualnym statusem dostępności.

• Korzystania z widoku kalendarza, który pokazuje zajęte i wolne terminy sal.

• Dodawania rezerwacji poprzez formularz, z uwzględnieniem walidacji danych oraz sprawdzaniem kolizji terminów.

• Przeglądania własnych rezerwacji oraz anulowania ich w razie potrzeby, z ograniczeniem: anulowanie rezerwacji jest niedozwolone na mniej niż 2 godziny przed rozpoczęciem spotkania.

• (Dla użytkowników z uprawnieniami administratora) Zarządzania salami i rezerwacjami w panelu administracyjnym – dodawanie oraz edycja sal konferencyjnych oraz edycja rezerwacji.

Podczas implementacji funkcjonalności należy uwzględnić:

• Walidację formularzy - tak aby wymagane pola były wypełnione, a wprowadzone dane poprawne.

• Sprawdzanie kolizji terminów - aby jedna sala nie mogła być zarezerwowana w tym samym czasie przez różnych użytkowników.

• Automatyczną aktualizację statusów rezerwacji po upływie terminu spotkania (np. zmiana statusu na „Zakończona”).

• Bezpieczeństwo danych, poprzez przypisanie odpowiednich ról użytkownikom i ograniczenie widoczności oraz możliwości edycji danych w zależności od uprawnień.

• Wsparcie dla automatycznych powiadomień i przypomnień o rezerwacjach

Dzięki tym założeniom aplikacja będzie nie tylko praktyczna i funkcjonalna, ale również bezpieczna i łatwa w użyciu, spełniając potrzeby zarówno zwykłych użytkowników, jak i administratorów systemu.

2. Tworzenie tabel i relacji w Dataverse

Podstawą każdej aplikacji biznesowej jest dobrze zaprojektowany model danych. W tym projekcie wykorzystaliśmy Microsoft Dataverse do przechowywania informacji o salach konferencyjnych oraz rezerwacjach.

2.1. Tabela SaleKonferencyjne

Ta tabela przechowuje wszystkie informacje o dostępnych salach w firmie. Zawiera kolumny takie jak:

• SalaID (Autonumber) - unikalny identyfikator sali

• NazwaSali (Text) - nazwa sali (wymagane)

• Lokalizacja (Text) - lokalizacja sali (wymagane)

• LiczbaMiejsc (Whole number) - liczba miejsc sali (wymagane)

• Opis (Text) - opis sali (wymagane)

• Dostępność (Yes/no) - informacja czy sala jest aktywna (wymagane)

• Wyposażenie (Multiselect choice) - np. projektor, TV, flipchart (opcjonalne)

• Zdjęcie (Image) - zdjęcie sali (opcjonalne)

2.2. Tabela RezerwacjeSal

Tabela RezerwacjeSal odpowiada za przechowywanie wszystkich dokonanych rezerwacji. Zawiera kolumny:

• RezerwacjaID (Autonumber) - unikalny identyfikator rezerwacji

• SalaID (Lookup do SaleKonferencyjne) - powiązanie z zarezerwowaną salą (wymagane)

• StartRezerwacji (Date and time) - początek rezerwacji (wymagane)

• KoniecRezerwacji (Date and time) - koniec rezerwacji (wymagane)

• StatusRezerwacji (Choice) - aktualny status rezerwacji: “Aktywna“, “Anulowana“ lub “Zakończona“ (wymagane)

• Cel (Text area) - cel spotkania (opcjonalne)

W Dataverse każda tabela posiada systemową kolumnę CreatedBy, przechowującą informacje o użytkowniku, który utworzył dany rekord. W naszym projekcie kolumna ta niejednokrotnie będzie wykorzystywana m.in. do filtrowania rekordów oraz wyświetlania informacji o osobie, która dokonała konkretnej rezerwacji.

2.3. Relacje między tabelami

W projekcie zastosowano relację jeden-do-wielu między tabelą SaleKonferencyjne a RezerwacjeSal. Oznacza to, że każda sala może mieć wiele rezerwacji, a każda rezerwacja jest przypisana tylko do jednej sali. Dzięki takiej strukturze łatwo filtrować rezerwacje dla konkretnej sali i utrzymać spójność danych w całym systemie.

3. Projektowanie UI - przegląd ekranów aplikacji

Aplikacja Sala+ została zaprojektowana z myślą o intuicyjnym i minimalistycznym interfejsie, który umożliwia użytkownikom łatwe przeglądanie dostępnych sal, zarządzanie rezerwacjami oraz kontrolowanie nadchodzących spotkań. Dodatkowo, dzięki zdefiniowaniu zmiennych przechowujących wartości kolorów w trigerze App OnStart, kolorystyka interfejsu może zostać w prosty sposób zmodyfikowana i dostosowana do aktualnych potrzeb.

Poniżej przedstawiam główne ekrany aplikacji wraz z opisem ich funkcjonalności i wizualnym podglądem.

3.1. Ekran startowy

Ekran startowy pełni funkcję powitalną. Użytkownik widzi nazwę i logo aplikacji oraz spersonalizowane powitanie. Przycisk „Rozpocznij” pozwala przejść do głównych funkcjonalności aplikacji.

3.2. Ekran “Sale Konferencyjne”

Ten ekran umożliwia użytkownikom przeglądanie dostępnych sal konferencyjnych. Zawiera listę sal wraz z podstawowymi informacjami, takimi jak nazwa oraz opis.

Po kliknięciu w “Szczegóły“ użytkownik może zapoznać się z bardziej szczegółowymi informacjami na temat wybranej sali oraz przejść do formularza rezerwacji sal po kliknięciu przycisku “Zarezerwuj“.

3.3. Ekran “Kalendarz rezerwacji“

Ekran „Kalendarz rezerwacji” pozwala użytkownikowi łatwo przeglądać wszystkie dokonane rezerwacje w formie wizualnej. Kontrolka kalendarza wskazuje dni z rezerwacjami za pomocą kropek, a po kliknięciu w konkretną datę wyświetlana jest lista rezerwacji na ten dzień – w tym nazwa sali, godziny rozpoczęcia i zakończenia oraz osoba, która dokonała rezerwacji. Dodatkowo użytkownik może filtrować rezerwacje po nazwie sali lub szybko wyczyścić filtry, aby zobaczyć pełny harmonogram.

3.4. Ekran “Dokonaj rezerwacji“

Ekran „Dokonaj rezerwacji” umożliwia użytkownikowi dodanie nowej rezerwacji poprzez intuicyjny formularz. Po prawej stronie znajduje się formularz, w którym użytkownik wybiera nazwę sali, datę i godzinę rozpoczęcia i zakończenia oraz cel spotkania. Po lewej stronie widoczny jest skrócony widok wybranej sali – nazwa, zdjęcie, liczba miejsc i wyposażenie – co pozwala użytkownikowi szybko zweryfikować szczegóły przed potwierdzeniem rezerwacji.

3.5. Ekran “Moje rezerwacje“

Ekran „Moje rezerwacje” umożliwia użytkownikowi szybki podgląd wszystkich swoich rezerwacji. Na liście widoczna jest nazwa sali, godziny rozpoczęcia i zakończenia, status rezerwacji oraz jej cel. Jeśli rezerwacja ma status „Aktywna” i rozpoczęcie spotkania jest odległe o więcej niż 2 godziny, użytkownik widzi przycisk pozwalający na jej anulowanie. Dodatkowo możliwe jest filtrowanie rezerwacji po statusie, nazwie sali lub dacie oraz szybkie wyczyszczenie wszystkich filtrów, co ułatwia odnalezienie interesujących informacji.

Po kliknięciu przycisku “Anuluj rezerwację“ pojawia się popup z zapytaniem, czy użytkownik na pewno chce anulować rezerwację.

3.6. Ekran “Panel Administratora“ zakładka “Rezerwacje“

Ekran „Panel administratora” – zakładka Rezerwacje umożliwia przeglądanie wszystkich rezerwacji dokonanych przez użytkowników. Na liście widoczna jest nazwa sali, godziny rozpoczęcia i zakończenia, status rezerwacji oraz użytkownik, który ją utworzył. Administrator ma możliwość edycji lub usunięcia każdej rezerwacji. Dodatkowo dostępne są filtry pozwalające wyszukiwać rezerwacje według nazwy użytkownika, statusu, nazwy sali oraz daty, a także opcja szybkiego wyczyszczenia wszystkich zastosowanych filtrów.

Po kliknięciu przycisku “Edytuj“ pojawia się formularz edycji wybranej rezerwacji.

Po kliknięciu przycisku “Usuń rezerwację“ pojawia się popup z zapytaniem, czy administrator na pewno chce usunąć rezerwację.

3.7. Ekran “Panel Administratora“ zakładka “Sale Konferencyjne“

Ekran „Panel administratora” – zakładka Sale Konferencyjne umożliwia przeglądanie wszystkich sal konferencyjnych w systemie. Administrator może przejść do edycji wybranej sali lub dodać nową salę konferencyjną, dzięki czemu łatwo zarządza zasobami dostępnymi dla użytkowników.

Po kliknięciu przycisku “Edytuj“ pojawia się formularz edycji sali.

Po kliknięciu przycisku “+“ z opisem “Dodaj nową salę“ pojawia się formularz umożliwiający dodanie nowej sali konferencyjnej.

4. Walidacje i logika biznesowa

Sama struktura danych oraz ekrany aplikacji nie wystarczą, aby zapewnić poprawne działanie systemu rezerwacji. Kluczowym elementem jest odpowiednia logika biznesowa oraz walidacje, które gwarantują spójność i bezpieczeństwo danych, a także komfort pracy użytkowników. W projekcie zaimplementowano szereg mechanizmów kontrolnych – od sprawdzania poprawności wypełnianych formularzy, przez zapobieganie kolizjom terminów, aż po automatyczne zmiany statusów rezerwacji i ograniczenia związane z możliwością anulowania spotkań.

4.1. Walidacja dat i godzin oraz sprawdzanie dostępności sali

Tworząc formularz dodawania nowej rezerwacji, należało zadbać o następujące zasady walidacji:

• Wszystkie pola oznaczone jako wymagane muszą zostać wypełnione.

• Rezerwacja nie może być dodana z datą lub godziną w przeszłości.

• Godzina zakończenia rezerwacji nie może być wcześniejsza niż godzina rozpoczęcia.

• Rezerwacja nie może zostać dodana, jeśli w wybranej sali istnieje już inna rezerwacja w tym samym przedziale czasowym.

Kod trigera OnSelect przycisku „Zatwierdź rezerwację” zawiera pełną logikę walidacji danych wprowadzanych przez użytkownika. W skrócie:

1. Tworzone są zmienne DateTimeStart i DateTimeEnd, które wskazują na datę i godzinę rozpoczęcia oraz zakończenia rezerwacji na podstawie wartości wybranych w formularzu.

2. Sprawdzana jest poprawność dat:

   • data rozpoczęcia nie może być przeszła,

   • data zakończenia musi być późniejsza niż data rozpoczęcia.

3. Następnie następuje weryfikacja dostępności sali – w wybranym terminie nie może istnieć już aktywna rezerwacja dla tej samej sali.

4. Jeżeli wszystkie warunki zostaną spełnione, formularz jest zatwierdzany (SubmitForm), użytkownik otrzymuje powiadomienie o powodzeniu operacji, a formularz jest resetowany, przygotowując go do wprowadzenia kolejnej rezerwacji.

//tworzenie zmiennych wskazujących na datę rozpoczęcia i zakończenia rezerwacji
Set(
    DateTimeStart,
    DateAdd(
        DateAdd(
            DateValue5.SelectedDate,
            Value(HourValue5.Selected.Value),
            TimeUnit.Hours
        ),
        Value(MinuteValue5.Selected.Value),
        TimeUnit.Minutes
    )
);
Set(
    DateTimeEnd,
    DateAdd(
        DateAdd(
            DateValue4.SelectedDate,
            Value(HourValue4.Selected.Value),
            TimeUnit.Hours
        ),
        Value(MinuteValue4.Selected.Value),
        TimeUnit.Minutes
    )
);

//sprawdzanie czy data rozpoczęcia nie jest datą przeszłą
If(
    DateTimeStart < DateAdd(
        Now(),
        0,
        TimeUnit.Minutes
    ),
    Notify(
        "Rezerwacja nie może zostać dokonana z datą przeszłą.",
        NotificationType.Error
    ),

//sprawdzanie czy data rozpoczęcia nie jest późniejsza niż data zakończenia rezerwacji
    If(
        DateTimeStart >= DateTimeEnd,
        Notify(
            "Data i godzina zakończenia muszą być późniejsze niż data i godzina rozpoczęcia.",
            NotificationType.Error
        ),

//sprawdzanie dostępności sali w wybranym terminie
        If(
            CountRows(
                Filter(
                    'Rezerwacje Sal',
                    SalaID.SalaID = Dropdown1.Selected.SalaID && 'Start Rezerwacji' <= DateTimeEnd && 'Koniec Rezerwacji' >= DateTimeStart && 'Status Rezerwacji' <> [@'Status Rezerwacji'].Anulowana
                )
            ) > 0,
            Notify(
                "W tym terminie sala jest już zarezerwowana",
                NotificationType.Error
            ),

//zatwierdzanie rezerwacji i resetowanie formularza
            SubmitForm(Form2);
            Notify(
                "Rezerwacja dodana pomyślnie!",
                NotificationType.Success
            );
            Set(
                varRec,
                Form2.LastSubmit
            );
            ResetForm(Form2);
        )
    )
)

4.2. Filtrowanie i wyświetlanie danych w galeriach

W aplikacji wykorzystano kilka galerii, dlatego istotne było, aby rekordy były wyświetlane w odpowiedni sposób, zgodnie z kontekstem danego ekranu i oczekiwaniami użytkownika.

Galeria w widoku Kalendarz rezerwacji wyświetla rezerwacje w porządku rosnącym według godziny rozpoczęcia, ograniczając widok do wybranego dnia w kalendarzu. Rekordy z anulowanymi rezerwacjami są pomijane, a dodatkowo można filtrować je po nazwie sali. Funkcja użyta do tego celu wygląda następująco:

SortByColumns(
    Filter(
        'Rezerwacje Sal',
        'Start Rezerwacji' >= DateAdd(
            _dateSelected,
            0,
            TimeUnit.Days
        ) && 'Start Rezerwacji' < DateAdd(
            _dateSelected,
            1,
            TimeUnit.Days
        ) && (SalaID.'Nazwa Sali' = Dropdown3_9.Selected.Value || IsBlank(Dropdown3_9.Selected.Value) && 'Status Rezerwacji' <> [@'Status Rezerwacji'].Anulowana)
    ),
    "kr_startrezerwacji",
    SortOrder.Ascending
)

Galeria w widoku Moje rezerwacje wyświetla wszystkie rezerwacje dokonane przez zalogowanego użytkownika. Rekordy są sortowane w kolejności malejącej według daty rozpoczęcia, dzięki czemu najnowsze rezerwacje pojawiają się na górze listy. Dodatkowo użytkownik może filtrować widok według:

• statusu rezerwacji,

• nazwy sali,

• daty rozpoczęcia rezerwacji.

Filtr uwzględnia tylko aktywne wartości w polach wyboru – jeśli filtr nie jest ustawiony, wszystkie odpowiadające rekordy są wyświetlane. Funkcja użyta do tego celu wygląda następująco:

SortByColumns(
    Filter(
        'Rezerwacje Sal',
        'Created By'.'Primary Email' = User().Email && (IsBlank(Dropdown3_3.Selected.Value) || 'Status Rezerwacji' = Dropdown3_3.Selected.Value) && (IsBlank(Dropdown3_4.Selected.Value) || SalaID.'Nazwa Sali' = Dropdown3_4.Selected.Value) && (IsBlank(DatePicker1.SelectedDate) || 'Start Rezerwacji' >= DateAdd(
            DatePicker1.SelectedDate,
            0,
            TimeUnit.Days
        ) && 'Start Rezerwacji' < DateAdd(
            DatePicker1.SelectedDate,
            1,
            TimeUnit.Days
        ))
    ),
    "kr_startrezerwacji",
    SortOrder.Descending
)

Galeria w widoku Panel Administratora – Rezerwacje umożliwia przeglądanie wszystkich rezerwacji w systemie. Rekordy są sortowane w kolejności malejącej według daty rozpoczęcia, dzięki czemu najnowsze rezerwacje pojawiają się na górze listy. Administrator może filtrować dane według:

• użytkownika, który utworzył rezerwację,

• statusu rezerwacji,

• nazwy sali,

• daty rozpoczęcia rezerwacji.

Filtry działają dynamicznie – jeśli pole wyboru jest puste, wszystkie odpowiadające rekordy są wyświetlane. Takie podejście pozwala administratorowi w szybki sposób odnaleźć interesujące rezerwacje i zarządzać nimi.

SortByColumns(
    Filter(
        'Rezerwacje Sal',
        (IsBlank(Dropdown3_7.Selected.Value) || 'Created By'.'Full Name' = Dropdown3_7.Selected.Value) && (IsBlank(Dropdown3_5.Selected.Value) || 'Status Rezerwacji' = Dropdown3_5.Selected.Value) && (IsBlank(Dropdown3_6.Selected.Value) || SalaID.'Nazwa Sali' = Dropdown3_6.Selected.Value) && (IsBlank(DatePicker1_1.SelectedDate) || 'Start Rezerwacji' >= DateAdd(
            DatePicker1_1.SelectedDate,
            0,
            TimeUnit.Days
        ) && 'Start Rezerwacji' < DateAdd(
            DatePicker1_1.SelectedDate,
            1,
            TimeUnit.Days
        ))
    ),
    "kr_startrezerwacji",
    SortOrder.Descending
)

4.3. Ograniczenia użytkowników

W aplikacji wprowadzono mechanizmy kontroli dostępu i ograniczenia funkcjonalne, mające na celu zapewnienie prawidłowego działania systemu oraz ochronę danych.

Pierwszą sytuacją uwzględnioną w ograniczeniach użytkowników jest brak możliwości rezerwacji sal oznaczonych jako „Niedostępna“. W takim przypadku przycisk „Zarezerwuj“ w widoku szczegółowym sali jest nieaktywny, a sama sala nie pojawia się w dropdownie formularza rezerwacji, uniemożliwiając jej wybór.

Wartość właściwości Items dropdowna służącego do wyboru sali została ustawiona za pomocą poniższego wyrażenia. Dzięki temu w dropdownie wyświetlane są tylko sale dostępne, posortowane rosnąco według nazwy sali:

Sort(
    Filter(
        'Sale Konferencyjne',
        Dostępność = true
    ),
    'Nazwa Sali',
    SortOrder.Ascending
)

Kolejną sytuacją jest widoczność sekcji Panel Administratora. W trigerze OnStart aplikacji ustawiana jest zmienna isAdmin. Kod sprawdza, czy aktualnie zalogowany użytkownik należy do określonej grupy Office 365. Jeśli tak – zmienna isAdmin przyjmuje wartość true, jeśli nie – isAdmin = false.

Set(
    isAdmin,
    !IsBlank(
        LookUp(Office365Groups.ListGroupMembers("899c8404-8f9d-4df7-aedf-ed6704503ead").value,
        mail = User().Email
    )
));

W menu bocznym, dla przycisku “Panel Administratora”, wartość właściwości Visible została ustawiona na isAdmin. Dzięki temu przycisk jest widoczny wyłącznie dla użytkowników należących do określonej grupy administracyjnej.

Dla realizacji tego mechanizmu w aplikacji został dodany konektor Office365Groups, umożliwiający pobieranie członków grupy Office 365 i weryfikację uprawnień użytkownika.

Widok menu bocznego dla użytkownika z uprawnieniami administratora:

Widok menu bocznego dla użytkownika bez uprawnień administratora:

4.4. Zarządzanie statusem rezerwacji

Status rezerwacji “Zakończona“

Jednym z założeń aplikacji było zapewnienie automatycznej aktualizacji statusów rezerwacji po upływie terminu spotkania. W docelowym rozwiązaniu mechanizm ten powinien zostać zaimplementowany przy pomocy Power Automate Flow, który uruchamiałby się cyklicznie i zmieniał statusy rezerwacji w bazie danych. Niestety, w przypadku darmowego konta developerskiego Power Platform istnieją ograniczenia – Dataverse jest traktowany jako connector premium, a jego obsługa w Power Automate nie jest dostępna w tej wersji.

Z tego względu zachowanie to zostało zasymulowane w aplikacji. W zdarzeniu App OnStart umieszczono wyrażenie:

UpdateIf(
    'Rezerwacje Sal',
    'Status Rezerwacji' = [@'Status Rezerwacji'].Aktywna && 'Koniec Rezerwacji' < DateAdd(
        Now(),
        0,
        TimeUnit.Minutes
    ),
    {'Status Rezerwacji': [@'Status Rezerwacji'].Zakończona}
);

Kod ten aktualizuje wszystkie rezerwacje posiadające status “Aktywna“, których czas zakończenia już minął, ustawiając im status “Zakończona”.

Należy jednak zaznaczyć, że rozwiązanie to nie jest idealne – wyrażenie uruchamia się dopiero w momencie startu aplikacji, więc do tego czasu statusy pozostają niezmienione. Ma ono jedynie na celu zasymulowanie poprawnego działania aplikacji. W pełnej wersji (z wykorzystaniem Power Automate i connectorów premium) taki mechanizm mógłby działać w sposób w pełni automatyczny.

Status rezerwacji “Anulowana“

Kolejnym założeniem dotyczącym zarządzania statusem rezerwacji jest możliwość anulowania danego rekordu przez użytkownika, z zaznaczeniem, że anulowanie rezerwacji jest niedozwolone na mniej niż 2 godziny przed rozpoczęciem spotkania.

W rekordach rezerwacji użytkownika przycisk „Anuluj rezerwację” jest widoczny tylko wtedy, gdy rezerwacja posiada status “Aktywna” i do rozpoczęcia rezerwacji pozostało więcej niż 2 godziny. W przeciwnym razie przycisk jest nieaktywny, a obok niego wyświetlana jest ikonka „i” z podpowiedzią:
„Nie można anulować rezerwacji — do rozpoczęcia pozostało mniej niż 2 godziny.”

Widok aktywnego przycisku “Anuluj rezerwację“:

Widok nieaktywnego przycisku oraz podpowiedzi:

4.5. Powiadomienia i integracja z kalendarzem

Kolejnym założeniem aplikacji było powiadamianie użytkowników o dokonanych rezerwacjach oraz przypominanie o nadchodzących spotkaniach. W idealnym scenariuszu mechanizmy te zostałyby zaimplementowane przy pomocy Power Automate Flow, które – w momencie utworzenia rekordu w tabeli Rezerwacje Sal – automatycznie wysyłałyby wiadomości e-mail z potwierdzeniami i przypomnieniami. Niestety, z uwagi na ograniczenia darmowego konta developerskiego (brak dostępu do connectorów premium, w tym Dataverse), konieczne było zastosowanie alternatywnego rozwiązania.

Potwierdzenie rezerwacji

Po pomyślnym zapisaniu formularza rezerwacji uruchamiane są dwie akcje w zdarzeniu OnSuccess:

1. Wysłanie wiadomości e-mail z potwierdzeniem rezerwacji, zrealizowane przy użyciu connectora Office365Outlook i metody SendEmailV2(). Wiadomość zawiera dane takie jak: sala, termin spotkania oraz ewentualny cel rezerwacji. Dzięki formatowaniu HTML wiadomość jest czytelna i profesjonalna.

Office365Outlook.SendEmailV2(
    User().Email,
    "Potwierdzenie rezerwacji: " & LookUp(
        'Sale Konferencyjne',
        SalaID = varRec.SalaID.SalaID
    ).'Nazwa Sali',
    "Cześć " & User().FullName & ",<br><br>" & "Potwierdzamy dokonanie rezerwacji w czasie: " & Text(
        varRec.'Start Rezerwacji',
        "dd mmmm yyyy HH:mm",
        "pl-PL"
    ) & " - " & Text(
        varRec.'Koniec Rezerwacji',
        "dd mmmm yyyy HH:mm",
        "pl-PL"
    ) & "<br>Miejsce spotkania: " & LookUp(
        'Sale Konferencyjne',
        SalaID = varRec.SalaID.SalaID
    ).'Nazwa Sali' & If(
        !IsBlank(varRec.Cel),
        "<br>Cel spotkania: " & varRec.Cel
    ) & "<br><br>Pozdrawiamy," & "<br>Zespół Sala+",
    {IsHtml: true}
);

2. Dodanie wydarzenia do kalendarza użytkownika (V4CalendarPostItem()) – zastosowane jako obejście problemu przypomnień. Każde wydarzenie ma ustawione automatyczne przypomnienie na 60 minut przed rozpoczęciem spotkania. W ten sposób udało się zasymulować mechanizm przypomnień, którego nie można było zrealizować poprzez Power Automate.

Office365Outlook.V4CalendarPostItem(
    "Calendar",
    "Rezerwacja: " & LookUp(
        'Sale Konferencyjne',
        SalaID = varRec.SalaID.SalaID
    ).'Nazwa Sali',
    Text(
        varRec.'Start Rezerwacji',
        DateTimeFormat.UTC
    ),
    Text(
        varRec.'Koniec Rezerwacji',
        DateTimeFormat.UTC
    ),
    "UTC",
    {
        Body: "Twoja rezerwacja sali konferencyjnej",
        Location: LookUp(
            'Sale Konferencyjne',
            SalaID = varRec.SalaID.SalaID
        ).'Nazwa Sali',
        IsReminderOn: true,
        ReminderMinutesBeforeStart: 60
    }
)

Potwierdzenie anulowania rezerwacji

Podobny mechanizm działa przy anulowaniu rezerwacji – użytkownik otrzymuje wiadomość e-mail z informacją o anulowaniu spotkania. Wiadomość zawiera również przypomnienie o konieczności ręcznego usunięcia wydarzenia z kalendarza, ponieważ obecna implementacja nie obsługuje tej operacji automatycznie.

Office365Outlook.SendEmailV2(
    User().Email,
    "Potwierdzenie anulowania rezerwacji: " & LookUp(
        'Sale Konferencyjne',
        SalaID = varRec.SalaID.SalaID
    ).'Nazwa Sali',
    "Cześć " & User().FullName & ",<br><br>" & "Właśnie anulowałeś rezerwację zaplanowaną na: " & Text(
        varRec.'Start Rezerwacji',
        "dd mmmm yyyy HH:mm",
        "pl-PL"
    ) & " - " & Text(
        varRec.'Koniec Rezerwacji',
        "dd mmmm yyyy HH:mm",
        "pl-PL"
    ) & " w " & LookUp(
        'Sale Konferencyjne',
        SalaID = varRec.SalaID.SalaID
    ).'Nazwa Sali' & ".<br>Nie zapomnij nanieść zmian w swoim kalendarzu." & "<br><br>Pozdrawiamy," & "<br>Zespół Sala+",
    {IsHtml: true}
);

Ograniczenia rozwiązania

Należy podkreślić, że jest to rozwiązanie zastępcze – dodawanie wydarzeń do kalendarza nie było pierwotnym założeniem aplikacji, a jedynie sposobem na obejście braku możliwości korzystania z Power Automate. Dzięki temu użytkownicy otrzymują przypomnienie o rezerwacji, jednak proces nie jest w pełni zautomatyzowany (np. brak możliwości automatycznego usuwania wydarzeń po anulowaniu). W docelowym wdrożeniu, przy pełnych licencjach, mechanizmy te mogłyby zostać zrealizowane w sposób bardziej profesjonalny i kompletny.

4.6. Uprawnienia użytkowników

Uprawnienia administratora

Na potrzeby aplikacji zostały utworzone konta pracowników firmy w Azure Entra ID. Dodatkowo stworzono dwie grupy typu security – Employees oraz Admins. Na tej podstawie weryfikowany jest dostęp do wspomnianego wcześniej Panelu Administratora:

• użytkownicy przypisani do grupy Employees posiadają wyłącznie standardowe funkcjonalności aplikacji,

• członkowie grupy Admins uzyskują dostęp do rozszerzonych funkcji administracyjnych.

Role bezpieczeństwa w Power Platform

Kolejnym krokiem było nadanie odpowiednich uprawnień w Power Platform Admin Center. W tym celu stworzono dwie nowe role bezpieczeństwa (security roles):

• Employee Role – rola przypisana standardowym użytkownikom aplikacji.

  • Dla tabeli Rezerwacje Sal: uprawnienia Create: User, Read: Organization, Write: User, Delete: None.

  • Dla tabeli Sale Konferencyjne: uprawnienia ograniczone do Read: Organization (tylko odczyt).

• Admin Role – rola przypisana administratorom.

  • Dla tabeli Rezerwacje Sal: pełny dostęp (Create, Read, Write, Delete: Organization).

  • Dla tabeli Sale Konferencyjne: pełny dostęp do edycji danych (Create, Read, Write, Delete: Organization).

Dzięki temu udało się odseparować standardowych użytkowników od administratorów, zapewniając właściwy podział ról i bezpieczeństwo danych w aplikacji.

5. Podsumowanie i wnioski

Celem projektu było przygotowanie aplikacji umożliwiającej rezerwację sal konferencyjnych w firmie, z uwzględnieniem logiki biznesowej, walidacji danych oraz kontroli dostępu użytkowników. W ramach realizacji zadania wdrożono mechanizmy: walidacji pól formularza, filtrowania i prezentacji danych w galeriach, obsługi statusów rezerwacji, a także ograniczeń w dostępie do funkcjonalności w zależności od roli użytkownika.

W trakcie pracy pojawiły się pewne ograniczenia wynikające z korzystania z darmowego konta Power Platform Developer – przede wszystkim brak możliwości wykorzystania Power Automate z konektorami premium. W związku z tym część funkcjonalności musiała zostać zasymulowana w kodzie aplikacji. Mimo tych ograniczeń udało się przygotować działające rozwiązanie, które w pełni spełnia początkowe założenia.

Wnioskiem z realizacji projektu jest potwierdzenie, że platforma Power Apps umożliwia w krótkim czasie zbudowanie użytecznej aplikacji biznesowej, nawet przy ograniczonych zasobach. Jednocześnie widać wyraźnie, że wykorzystanie pełnego środowiska produkcyjnego wraz z Power Automate oraz rozszerzonymi konektorami znacząco zwiększyłoby możliwości i pozwoliło na pełną automatyzację procesów.