Chatbot-PROCEED Interaction

[iaktern]

Chatbot Interaction:

• Step 1 - LLM Explanations: connect PROCEED, transfer functions, make two step request working (1. first list all processes, 2. then looking deeper into one specific process), answer questions of user
  • wiki: document how to register PROCEED and which functions are given to the LLM: https://github.com/PROCEED-Labs/proceed/wiki/MS-LLM-MCP-Interactions
    • How much data about every process do we send to the chatbot at once? -> Sending all data (processes, meta, content) at once is probably too much. Not too fine granular, but a bit: get all processes meta data, get a specific process, get org data, get user data
  • Authentication of a user -> for now, no auth, LLM has access to one specific organization. (Later: llm has only access to the data of the user)
  • test with the vacation process and other processes:

• Step 2 - Data Retrieval: include user and org data in LLM interactions, e.g. the remaining vacation days (open tasks: see earlier)
  • Bug - "Data" view: within the editor, it is not possible to go back to the full view of all parameters after you clicked on one parameter in the tree view. -> Make the Breadcrump menu clickable to go back to top element view
  • Data view: the changeableByUser attribute should allow to add subparameter so that adding further Data Objects within User -> Data is possible. (Optional: It would even be nice to be able to add new sub-parameters under objects copied from "Common User Data")
  • Data view: "User Info" section as a sibling object to "Data" inside the Template for every user. It should have virtual Data Objects to the existing data within PROCEED. Predefined parameters: Name, First-Name, Last-Name, Username, E-Mail, Team, Direct-Manager, Back-Office. also add a good description for the LLMs to understand. virtual Data Objects should not be changeable (nor now)
  • Extend User Profile with new inputs to link a "Team" (role), "Direct-Manager" (user), "Back-Office" (role): create a new DB table per space for this "organigram" info (don't extend the membership table)
    • Extend the "Invite User" and "Create User" modal within the "Users" view under "Organization" with the new input fields
    • Add an "Edit" icon + modal for the user data within the "Users" view under "Organization" (not just delete icon)
    • (low prio) Create a new "Team" view under "Organization" (not in personal spaces) which every user can access by default to see their team name/role (if possible, with all members of the team role), direct manager and backoffice. This should be read-only - a normal user should not be able to change this info (just admins in "Organization" -> "Users")
  • (low prio) Data view: "Roles" section as 1. a sibling object to "Data" inside the Template for every user and 2. under IAM as a sibling of "User". The latter should also contains every assigned user as a child element. It should have virtual Data Objects to the existing data within PROCEED.
  • (low prio) Remove "Data" view from "Personal" - visible under "Home/Organization" for everyone. but only with a new permission a user is allowed to see the whole org structure and all users. For now, only a simple permission system: @everyone should always be able to see their user data in the "Data" view under "Home/Organization" (default), but add two new Permission "Organization Data Objects" (1. View + 2. Manage all organizational Data Objects) that enables a user to see/change all data objects. The @admin role should have both permissions by default.
    • Exception: For Personal Spaces there is no role and permission system. so the user is also the admin in his own space. therefore they should always "have" the two new permissions.

---

Vacation Requests Automated.zip

• Step 3 - start process: deploy (if not already done), start instance, fill variables from empty start event

  • add button in the process list to start a process (result: since the process list is connected with the permissions, a user is only able to start the processes she has access to)
  • The LLM needs to differentiate between automatable and non-automatable processes: if a process is non-automatable, then the LLM explains the whole process to the user. if a process is automatable, then the LLM should also offer to start the process for her/him.
  • Start a process with an LLM: deploy the newest process version and start a new instance. if there are process variables required at startup, the LLM needs to request them from the user and the MS needs to transform them to the correct datatype. afterwards start the instance with the process variables.
  • Engine: For starting a new process instance extend the Engine to retrieve data (optional, not mandatory) about 1. the location of the MS (array to test multiple locations), 2. the user-id of the process initiator, 3. the space-id of the user. Store this information inside the process instance property managementSystemLocation: "", processInitiatorId: "", spaceIdOfProcessInitiator: ""
    • MS: Start a new process instance and send multiple location information about the MS to the Engine (os.hostname() + port (aus NEXTAUTH_URL), NEXTAUTH_URL, (IP addresses read by Engine)), the user id and the space id
    • (low prio) Engine: add a new config to store a default location for the MS
  • change script functions in Engine and in Monaco Editor: getGlobal() -> getProcess(), .getAllGlobal() -> .getAllProcess(), .getWithLogsGlobal() -> .getWithLogsProcess(), setGlobal() -> setProcess()
  • add new script functions in Engine and in Monaco Editor: getGlobal(), getGlobalFull(), getGlobalOrg(), getGlobalOrgFull(), setGlobal(), setGlobalOrg() -> take the first working location of the MS (sequence: hostname, URLs, IPs, Engine config), if no port is given then try the standard ports 80, 443, 33081
    • implement throwing Errors if 1. the Data Object does not exist while reading and writing, 2. the global Data Store (MS) is not reachable
  • UserTasks Editor: implement the notation in the HTML to retrieve/write global Data Objects like described here
    • UserTasks Editor: implement UI to select Data Objects of the global Data Store inside the UserTask Editor
    • UserTasks: implement functionality in the MS Tasklist to retrieve/write global Data Objects directly inside the MS
  • REST API Extension for retrieving/setting data in the global Data Store:
    • Dot-notation for endpoints requesting a specific parameter: /spaces/{space-id}/configurations/{config-container-id-or-shortName}/latest-parameter/{parameter-id-or-parameter-name} -> 'IAM.User.id.Data.Vacation.RemainingDays'
    • Bug: parameter on the same level must not have the same name. Capitalization must be irrelevant, i.e. upper and lower case letters are the same. -> dot-navigation must ignore the capitalization.
    • Space Status endpoint: GET /spaces/{space-id}/status?user-id=<uuid> with 200 or 404 return
    • Simplification endpoints for retrieving the data from user/org section: GET/PUT /spaces/{space-id}/data/organization/{data-object-id-or-name} and GET/PUT /spaces/{space-id}/data/user/{user-id}/{data-object-id-or-name}
  • (low prio) implement the role and permission system inside the "Executions" view, so that a user can only see her started processes. (Currently, everyone with access can see all processes)
  • (low prio) permission system for accessing the Data Views: there should be a permission to give to normal users to 1. read and 2. write data in the organizational data space. there should be another permission which allows reading and writing in the user data spaces
    • (low prio, later) make the permission system more fine granular on the data level, so that every data object can be read/written by specific persons/roles
  • (low prio) if a process tries to write into the global Data Store (user data or organizational data), the PROCEED Engine sends this request to the MS via the REST API. (or with a UserTask directly in the MS) for this reading or writing, check if the user has the permissions to do it (OPEN QUESTION: UserTasks can access process-initiator data and current worker -> when to allow this?)
  • create/think about a concept of the following topics and implement them for the automation part:
    • (low prio) for the UserTasks: how to assign the employees boss and the office, which can not be hard-coded since they change from user to user
    • (low prio) the data object "Remaining Vacation Days" is not allowed to be changed by the user directly in the UI (achieved with the attribute changeableByUser: false. It is only changeable with the REST API, so: it is only changeable by processes. Problem: The user can create her own process and change the variable. -> how to extend parameters or processes, so that only released processes (by a responsible person) can change these parameters? a user should still be able to change her self-created data objects.

• Step 4. - Instance Status: ask questions about the process status

  • Step 4.1: the Chatbot should tell the user, if there is an open task for him and what to do. It would be good, if the chatbot can ask the User to give specific data, which it writes back to PROCEED (this mean: working on open user tasks

• Step 5. - Full Automation / Tasklist in LLM: check if a user can be notified (push) with "GPTs" or "Apps" to automate the full process

• Step 6. Not just Happy Path:

  • UserTasks with Decline Buttons
  • Inform the Process Initiator of the Result

Configs and new Navigational Elements in PROCEED:

• Config Editor: remove top root element in TreeView (currently the block [TDS] <id>)
• create "Configurations" view as a parent entry; above "Automations"; only with "New: Empty" button
• create new "Data" view as a child entry under Home/Organizational that directly opens the Config Editor; use given template for every Space (see file)
  • there are separate Data parent parameter under Organization and under IAM -> User -> <user-id>. this is to extend this structure later on with other data objects from the MS, e.g. processes, machines, etc.
  • in the screenshot you only see the Display Name. the Parameter Name is usually in lowercase and with - as space
  • IAM -> User -> <Lastname, Firstname> is only the display name. the parameter-name would be the <user-id> (QUESTION: should the user-id and parameter-id maybe be the same?)
  • by default, there should be no child parameters inside Organization -> Data AND none in IAM -> Common User Data AND none in IAM -> User -> <user-id> -> Data. All you see in the screenshot and files are examples. We will add this data during runtime
  • the users should only be able to add and change new parameters under the following parent elements:
    Organization -> Data
IAM -> Common User Data
IAM -> User -> <user-id> -> Data
    For this, is the existing attribute changeableByUser: false on all other elements sufficient? does it also prevent from creating new child parameter?
  • "Common User Data" should be a special parameter: every child parameter (also new ones) must be copied (not linked) to a new parameter under IAM -> User -> <user-id> -> Data for every user. the copied parameters must have changeableByUser: false, so that the user can not by itself change them. The parameters should also be synchronized: if a child parameter is deleted from "Common User Data", it should also be deleted from every user "Data"
  • in the Edit mode, can we simply add two new buttons to "Add Org Data" and "Add User Data" (writes to Common User Data). They should not show up in the Empty Editor (like the special buttons for the TDS Editor).
  • language selection dialogs for data management in Organization and Personal should default to "English".
  • (low prio) fix the permission problem that every user account can access the config id
• create new "Data" view as a child entry under "Personal" that directly opens the Config Editor
  • for now, only every parameter under IAM -> User -> <user-id> -> Data should be shown (not even Data as a parent object)
  • language selection dialogs for data management in Organization and Personal should default to "English".
  • in the Edit mode, can we simply add a new button to "Add User Data". This button should not show up in the Empty Editor (like the special buttons for the TDS Editor).

Space-Name Data Objects_internal_format.json