Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Use the Auth package to allow ProcessMaker users to log on using SSO, SAML, LDAP and SCIM authentication protocols.
Use the Auth package to authenticate ProcessMaker Platform users to log on using any of the following protocols:
Lightweight Directory Access Protocol (LDAP): Synchronize users from LDAP organization to ProcessMaker Platform.
SSO via Security Assertions Markup Language (SAML) 2.0: SAML is an open-standard format to exchange authentication and authorization data between parties when establishing a SSO session.
System for Cross-domain Identity Management (SCIM): SCIM is an open standard that allows for the automation of user provisioning.
The Auth package is based on OAuth 2.0 framework, which is an open-standard authorization protocol that describes how unrelated servers and services can securely authenticate access to their assets without sharing log on credentials.
Request participants can make decisions via email with the click of a button.
Use the Actions By Email package to send emails automatically during your Processes' Requests. During a Request, email recipients can make business decisions directly in the email by clicking on a button to indicate that decision. The email response returns to your ProcessMaker Platform instance to acknowledge the decision, then routes workflow for that Request. While an email may be sent to multiple recipients, only the first response is acknowledged to affect workflow in that Request.
The Actions By Email package has the Actions By Email connector that integrates into Process Modeler. Use the Actions By Email connector as you would BPMN elements: drag and place the Actions By Email connector into your Process model, configure its settings, and then add its incoming and outgoing Sequence Flow elements.
When the Actions By Email connector triggers during an in-progress Request, ProcessMaker Platform sends an email from the "no-reply@processmaker.net" email address to one email recipient so that this Request participant can make a decision as part of the Request. For example, this Request participant must make a decision to approve or deny a vacation request or for a purchase. The email recipient receives an email with buttons in the email to easily indicate the decision.
After the email recipient clicks a button to indicate the decision, ProcessMaker Platform receives the response and uses the indicated decision as part of the Request routing. For example, if you grant a leave request, the Request routes differently than if you deny that leave request.
Email design is subject to email client limitations and may not fully support HTML5 or CSS3 specifications. Test your emails in your supported client applications.
See the following for more information:
Packages extend functionality from the ProcessMaker Platform Open-Source edition. None of these packages are available in the Open-Source edition. These are available only for the Enterprise edition.
In the context of ProcessMaker Platform, a package is a stand-alone container to distribute and install a or to extend current functionality.
Technically, a package in ProcessMaker Platform is a compound from routes, controllers, models, and other assets that have a Provider class that functions as a union bridge between ProcessMaker Platform and the Laravel package from which ProcessMaker Platform is built.
Do you want to design your own packages for ProcessMaker Platform, regardless of whether you use the Open-Source edition or an Enterprise customer? Develop your own custom package for use in ProcessMaker Platform.
Create multiple sets of schema-less data records using Screens that do not require an external database.
Use the Collections package to maintain sets of schema-less data records using , each referred to as a . The Collections package has the following features:
An external database is not required to store Collections. Collections are maintained in the ProcessMaker instance.
A Collection is composed of a set of records. Similar to a relational database, a record is a grouping of fields that represent related data. Design the grouping of fields using Screens to represent this data, thereby making it easy for any user to view, create, or edit record data if they have the appropriate permission(s) to do so. Within a Collection, potentially use different Screens to create a record, edit a record, or view a record within that Collection. This provides greater control in how information within a Collection is consumed by various stakeholders in the Collection. Consider the following use case:
Create a record: Allow an assistant to create a record using Screen for this purpose, such as in a medical practice.
Edit a record: In the same medical practice, a dedicated Screen allows a nurse to edit patient information after the new patient has granted legal permission for medical staff to edit sensitive medical information (in compliance with HIPAA standards).
View a record: Use a third Screen that references identical record information, but limits the content and editing so that the medical practice complies with patient legal protections.
Collections are schema-less, meaning that any type or format of data may be stored in a Collection. Because Collections are schema-less, changing the thereby changes the types of information or data to all records within that Collection. You are not constrained by how you define a Collection when you create it. For example, if you want to allow Collection stakeholders to attach a file that becomes associated with a record, add a in the applicable Screen(s) that represent information in that Collection; the new File Upload control becomes available in all records in that Collection.
Determine which users and/or groups have permission to view, create, edit, or delete Collections by setting . These permissions are different than that specify which users and/or groups can manage records within an individual Collection.
into a Collection to simultaneously create multiple records from the CSV file's data records.
The Collections package integrates with the Saved Searches package. Use the Saved Searches package to save and share searches associated with a Collection. See Saved Searches Package. Use ProcessMaker Query Language () parameters to compose queries to . Furthermore, changes to a Collection may then be applied to Saved Searches associated with that Collection.
Establish . A Collection relationship links two Collections by designating one Collection as a parent Collection, the other as a child Collection, and defining data keys or columns linking both Collections. The Collection from which this relationship is created is automatically designated as the parent Collection. The relationship is a one-to-many relationship such that a record in the parent Collection can have multiple matching records in the child Collection.
An external database is not required to store Collections. Collections are maintained in the ProcessMaker instance.
The Collections package integrates with the Saved Searches and Data Connector packages:
Saved Searches package: Use the Saved Searches package to save and share searches. See Saved Searches Package.
Data Connector package: Access both Collection records and third-party data sources from any ProcessMaker asset, including Screens, Scripts, and Process models. See Data Connector Package.
Access both Collection records and third-party data sources from any ProcessMaker Platform asset, including Screens, Scripts, and Process models.
Use the Data Connector package to connect your ProcessMaker Platform assets, such as Screens, Scripts, and Collections to and from third-party data sources such as Application Program Interfaces (APIs). After a Data Connector is created, Process designers can reference the data source via the Data Connector from within their ProcessMaker Platform assets. Incorporating data from external data sources such as APIs helps you make business decisions from information outside of your ProcessMaker Platform instance.
Below are a few ways to use Data Connectors:
In Screen Builder, use the records in a Collection as Select List control options in a Screen.
In Screen Builder, use a Watcher to act on data from a Data Connector when the value of a Screen control changes.
While modeling a Process, place a Data Connector connector into your Process model to automatically access records from a Collection records or access external data from a third-party data source to incorporate new information into Requests started from your Process. After this external data has been incorporated into Requests, make business decisions based on that data.
The Data Connector package has the following components after it is installed:
Manage Data Connectors: from one place. After your Data Connectors are configured, your Process designers can access them from their ProcessMaker Platform assets.
Process model connector: A is a control that integrates into Process Modeler. Use the Data Connector connector as you would : drag and place the Data Connector connector into your Process model, configure its settings, and then add its incoming and outgoing Sequence Flow elements.
Screen Builder controls: Interact with Collection records and third-party data source directly from within specific Screen Builder controls, such as the and controls.
Design functional rule-based modern chat style forms using Screens in ProcessMaker Platform.
Use the Conversational Forms package to design functional rule-based modern chat style forms using with the -type Screen.
The Conversation Forms package has the following features and attributes:
When your Conversational-type Screen renders, that Screen displays as a streaming interactive form that supports rich text, text input, and multiple choice options that can be validated based on the reader's input.
Screen control labels and values create a conversational flow with the reader. As the form renders from top to bottom, each Screen control displays as a "chat style" instruction or question. The interactive form scrolls up the page and the next Screen control displays as the reader responds to each instruction or question. If an interstitial Screen is used, an animated GIF of dots displays as if someone is chatting with the reader.
Integrate Request variable values within the reader conversation as you would in Form-type Screens. For example, if the reader's name is known from a parent Request and stored in a Request variable, use to reference that Request variable's value within a Rich Text control to display that reader's name in a personalized message within the chat response.
Determine when the reader has deserted the chat experience. Each reader response to the chat experience resets a timeout counter. If the counter expires, a message displays Are you still there? and then begins a final countdown. If the timer expires or the reader navigates away from that page, then the accumulated chat content automatically submits and completes with a message This conversation has expired. with a button to restart the chat experience which reads Start Over.
After designing your Conversational-type Screen, embed it to a third-party site to provide site visitors an automated chat-style interaction.
Documentation for your Processes that includes an image of the Process map, lists all its elements and connectors, and their functional descriptions.
Use the Documentation package to enter and view documentation for your Processes. Entered documentation is for informational purposes only and does not affect Request workflow.
The documentation displays as a page within ProcessMaker Platform. Use the Web browser to print or save as a PDF if your browser supports those functions.
Process documentation has the following attributes:
The page generated by the Documentation package provides the following information about the Process:
The name of the Process.
When was the Process was last updated and by whom.
A description of the Process as entered when creating a new process.
An image of the Process map.
Names of all Process elements and their unique node IDs.
The documented description of each Process element and/or connector. If no description has been entered for an element/connector, No Documentation Found message displays.
Below is a documented Process.
See the following topics regarding how to view Process documentation and edit the description for Process elements and/or connectors:
Customize and send documents for signatures by fully integrating DocuSign’s eSignature functionality into your Processes.
Use the DocuSign package to customize and email your documents for signatures. DocuSign eSignature provides a service to digitally sign legally-binding documents including contracts, account openings, and invoices. ProcessMaker Platform uses DocuSign's eSignature API to allow Process designers to seamlessly integrate this functionality in a Process.
After the DocuSign package is installed, the DocuSign connector integrates into the Process Modeler. Use the DocuSign connector in your Process models as a BPMN element: drag and place the DocuSign connector into your Process model, configure its settings, and then add its incoming and outgoing Sequence Flow elements.
The DocuSign connector uses DocuSign templates and recipient roles to send documents for eSignatures. Documents are sent through email to internal and external users as part of a Process. During a Request, when the DocuSign connector triggers, workflow routing can be configured in one of the following ways:
The Request pauses until the assigned user signs the document.
The Request's workflow resumes independently of the document's signing status.
For information on DocuSign templates and recipient roles, refer to Working with Templates - DocuSign eSignature User Guide.
Using the DocuSign package is a multi-step process involving these user roles:
System Administrators: An Administrator configures DocuSign server settings to ensure access to your DocuSign server.
Process designers: A Process designer configures the DocuSign connector in a Process to email documents for eSignatures to the intended recipients.
Recipients or document signers: The recipients access the documents through an email sent by DocuSign and sign them. The documents can be signed by both ProcessMaker Platform or external users.
Follow these guidelines to use the DocuSign package:
.
Upload, preview and download documents during your Processes' Requests.
Use the File Manager package to preview, download, and share files during your Requests. The File Manager package has the following components after it is installed:
File Manager: Manage files that have been added to your personal file manager:
Manage files any user may access: .
Manage files that have been shared with you: .
Manage starred files: .
File Manager tab in Request summaries: uploaded to a Request in the File Manager tab. The File Manager tab replaces the Files tab in that is in the ProcessMaker open-source edition. From the File Manager tab, view, download, and share files from a Request summary.
Preview files in Tasks: Preview a file uploaded to a previous in that Request via a control.
Manage dashboards that display BMI and KPI metrics for stakeholders. Manage top-level menus that link to often-used ProcessMaker Platform locations, custom links, and often-used Requests.
Use the Dynamic UI package to design custom experiences in the following ways:
Create dashboards that display business management information (BMI) and key performance indicators (KPIs) at a glance for business stakeholders. Dashboards created in ProcessMaker Platform are Display-type Screens that can contain Saved Search charts and information designed to show relevant BMI and KPIs.
Configure a dashboard to be the default homepage for specific users and/or groups. When these users log on to ProcessMaker Platform, the dashboard displays content by default so that stakeholders can act on ProcessMaker Platform business data and information quickly. For example, create one dashboard for your Sales team that displays sales KPIs and another for dashboard that displays KPIs for your Marketing team.
Replace the top-level menus that display in ProcessMaker Platform. Instead of the default menu options, customize them to link to often-used ProcessMaker Platform locations such as Collections and Saved Searches to which those users and/or group members have access, often-started Requests, external links in your organization, or any other hyperlink that your users can expect to have access. Providing custom menus simplifies how users access ProcessMaker Platform and specific uses. For example, create one menu for your Sales team members that provides links to the in-progress Requests location and their Saved Searches they use to monitor their KPIs, but another menu for all users to start Requests for often-used Processes and access Human Resources information.
In conjunction with the Custom UI feature, customize the logo, color scheme, and/or font that displays across the ProcessMaker Platform interface. By creating custom top-level menus, effectively white-label the user interface so that your clients and/or partners do not know that they are using ProcessMaker Platform when they log on.
Show or hide ProcessMaker Platform user interface components for members of a group, including the left sidebar, the +Request button to start Requests, and the breadcrumbs.
After creating the dashboards and custom menus for your business stakeholders, assign them to those users and/or group members the next time those users log on to ProcessMaker Platform:
Request participants can auto-complete street, location, and/or business addresses entered into a Screen control.
Use the Google Places package to allow Request participants to do the following in Form-type Screens:
Start entering an address, location, or business name into a Screen control, then allow the Google API to auto-complete that address or location. The Google Place control stores the selected address in the Request data as well as all the returned data from the Google API.
View and/or select from one or more geographical locations in a Google map.
Prior to using the Google Places package, ensure that your organization has a with the and enabled, as well as API keys for each API.
The Google Places package has the following components after it is installed:
Screen Builder control: The Google Places package installs the Google Places control into Form-type Screens. After adding and configuring a Google Places control into your Screen, Request participants start entering an address, then receive auto-complete address options from which to select as the intended address, location, or business name. The Google Place control stores the selected address in the Request data using that control's Variable Name setting value, as well as all the returned data from the Google API. See .
Environment Variable: The Google Places package adds an called GOOGLE_API_TOKEN that contains the Google API token for that ProcessMaker instance. The Environment Variable does not require configuration or revision after it has been added to your ProcessMaker instance.
The Google Places control uses the Google API token to call the Google API when a Google Places control is placed into a Screen, then when address information is entered into the control. Google uses Basic Service Set Identifiers (BSSID) information from the Request participant's Wireless Local Area Network (WLAN) Access Point to get an approximation of where that Request participant is located, even when GPS and WiFi are not available.
Below are a few ways to use the Google Places package:
Allow Request participants to easily enter a shipping or billing address.
Enter a business name into the Google Places control to select a business location.
Enter well-known monuments or international airport names to get their addresses or locations when requesting to travel.
View Documentation for a process: from the Processes tab.
Start Event element configuration: for a Start Event element.
Start Timer Event element configuration: for a Start Timer Event element.
Signal Start Event element configuration: for a Signal Start Event element.
Message Start Event element configuration: for a Message Start Event element.
Conditional Start Event element configuration: for a Conditional Start Event element.
Intermediate Timer Event element configuration: for an Intermediate Timer Event element.
Intermediate Signal Catch Event element configuration: for an Intermediate Signal Catch Event element.
Intermediate Signal Throw Event element configuration: for an Intermediate Message Throw Event element.
Intermediate Message Catch Event element configuration: for an Intermediate Message Catch Event element.
Intermediate Message Throw Event element configuration: for an Intermediate Message Throw Event element.
Intermediate Conditional Catch Event element configuration: for an Intermediate Conditional Catch event element.
End Event element configuration: for an End Event element.
Message End Event element configuration: for a Message End Event element.
Error End Event element configuration: for an Error End Event element.
Signal End Event element configuration: for a Signal End Event element.
Terminate End Event element configuration: for a Terminate End Event element.
Form Task element configuration: for a Form Task element.
Manual Task element configuration: for a Manual Task element.
Script Task element configuration: for a Script Task element.
Sub Process element configuration: for a Sub process element.
Boundary Timer Event element configuration: for a Boundary Timer Event element.
Boundary Error Event element configuration: for a Boundary Error Event element.
Boundary Signal Event element configuration: for a Boundary Signal Event element.
Boundary Conditional Event element configuration: for a Boundary Conditional Event element.
Boundary Message Event element configuration: for a Boundary Message Event element.
Exclusive Gateway element configuration: for an Exclusive Gateway element.
Inclusive Gateway element configuration: for an Inclusive Gateway element.
Parallel Gateway element configuration: for a parallel Gateway element.
Event-Based Gateway element configuration: for an Event-Based Gateway element.
Pool element configuration: for a Pool element.
Lane element configuration: for a Lane element.
Text Annotation element configuration: for a Text Annotation element.
Message Flow element configuration: for a Message Flow element.
Actions by Email connector configuration: for an Actions by Email connector.
Data Connector connector configuration: for a Data Connector connector.
DocuSign connector configuration: for a DocuSign connector.
PDF Generator connector configuration: for a PDF Generator connector.
Send Email connector configuration: for a Send Email connector.
Slack Notification connector configuration: for a Slack Notification connector.
Integrate intelligent document processing (IDP) into your Processes.
The IDP package includes client-side features to ProcessMaker IDP. ProcessMaker IDP is ProcessMaker's intelligent document processing (IDP) solution.
ProcessMaker IDP is technology that uses Artificial Intelligence (AI) and Machine Learning (ML) algorithms to extract information and insights from unstructured data sources such as documents, images, and videos. ProcessMaker IDP can automatically classify, extract, validate, and transform data from different types of documents such as invoices, contracts, purchase orders, driver's licenses, and many others.
ProcessMaker IDP can benefit organizations in numerous ways. Use ProcessMaker IDP to reduce processing times, minimize errors, improve compliance, and enhance operational efficiency. Specifically, the benefits of including ProcessMaker IDP into workflow solutions may include the following:
Streamline business processes: ProcessMaker IDP can automate repetitive tasks related to document processing, freeing up staff to focus on higher value tasks. This can lead to streamlined business processes, and faster turnaround times.
Cost savings: ProcessMaker IDP can reduce costs associated with manual data entry and processing via automation. Furthermore, save costs by preventing costsly data re-entry related to human errors.
Improved compliance: ProcessMaker IDP can ensure that documents are processed in accordance with company policies and regulatory compliance.
Data insights: ProcessMaker IDP can help organizations to gain insights from documents, such as identifying opportunities for revenue growth and cost savings.
For example, ProcessMaker IDP can automate invoice processing: extract key data from invoices such as the vendor name, invoice date, invoice number, and the total amount, and then automatically validate and transform this data into a format that can be uploaded to the organization's accounting system.
The IDP package has the following components after it is installed:
IDP connector: Use to integrate ProcessMaker IDP into your business Processes.
IDP settings: Prior to using IDP connectors, .
Optimize workflow in your Process model by visually evaluating its workflow through its Sequence Flow elements without assigning Task recipients.
The Process Optimization package integrates into Process Modeler to visually validate the workflow in your Process model. Use visual validation to validate if workflow can potentially complete routing through all elements and/or connectors in your Process model. The Process Optimization package extends basic BPMN 2.0 validation to validate whether all workflows routes are viable, including connectors that do not apply to BPMN 2.0 validation.
The Process Optimization package has the following features:
Click the Check Flow button in the bottom bar of Process Modeler to automatically view how workflow routes in your Process model. Process Modeler evaluates workflow throughout your Process model, and then displays each possible workflow route results in separate sections. Process Modeler evaluates workflow based on the default Sequence Flow elements and/or conditions set to those Sequence Flow elements throughout the Process model.
Tasks need not be assigned to users/groups nor Sequence Flow elements configured with routing conditions.
Design business rules within decision tables that affect Process routing. Decision tables can be reused in any Process model.
A Decision Table is a two-dimensional grid that outlines the different possible business conditions that can occur for a particular data output. The data output then affects the workflow routing for any Request that references that decision table. The Decision Table represents business rules from which to evaluate how to route Requests for a Process.
Decision Tables are Decision Model and Notation (DMN) files. DMN is a standard notation to model and run decisions in business contexts, used by business analysts, developers, and Process designers to manage complex decision-making scenarios.
Decision Tables provide the following benefits versus only use BPMN elements to determine workflow routing:
Design complex sets of business rules more easily and with greater readability and transparency than using Gateway-type elements with Sequence Flow elements to determine workflow routing.
Decision Tables require no coding experience, allow most Process designers to easily design business rules.
Unlike BPMN elements, Decision Tables function independently of Process models. Similarly to Scripts, Screens, and Collections, Decision Tables are referenced from within Process models, thereby making them reusable and more flexible than only using BPMN elements.
Decision Tables are referenced from Rule Task connectors in a Process model. One Rule Task connector may reference multiple Decision Tables to determine complex routing decisions.
The Decision Tables package provides the following functions:
Design Decision Tables: Design Decision Tables in Decision Table Editor that can be reused in any Process to create complex yet easily configurable business rules. See these topics:
Automatically generate PDFs of Display-type Screens in a Process.
Use the PDF Generator package to automatically generate PDFs of Display-type Screens during Requests.
After the PDF Generator package is installed, the PDF Generator connector integrates into Process Modeler. Use the PDF Generator connector in your Process models as you would BPMN elements: drag and place the PDF Generator connector into your Process model, configure its settings, and then add its incoming and outgoing Sequence Flow elements.
Use the PDF Generator connector in your Process models when you want to provide a printable copy of a Display-type Screen, such as for Request summaries or purchase order receipts.
When the PDF Generator connector successfully generates the PDF during an in-progress Request, the PDF output can be downloaded from the Files tab in its Request summary. The PDF Generator by default names the PDF output the same as the Screen from which the PDF was generated unless the name is configured via text or by referencing a Request variable using mustache syntax. If the PDF Generator successfully generates the PDF, the PDF output remains available from that Request's summary regardless of that Request's status.
See the following topics:
, which contains the same information as that for other Request statuses
Send emails automatically during your Processes' Requests.
Use the Send Email package to automatically send emails during your Process Requests. The Send Email package has the following components after it is installed:
Process model connector: The integrates into Process Modeler. Use the Send Email connector in your Process models as you would BPMN elements: drag and place the Send Email connector into your Process model, configure its settings, and then add its incoming and outgoing Sequence Flow elements.
New Screen type: The Send Email package adds a new Screen type called Email. Use an email-type Screen to compose the email body for email messages to sent with the Send Email package. In doing so, use Variable Name setting values from Screens referenced in a Process model to customize the sent email. The content of referenced Email-type Screens become the email body content. When creating a new Screen, select the Email type.
Send email notifications from Task and Manual Task elements: Send email notifications when a Task or Manual Task element triggers, completes, or under a specified condition. Include either plain text or the contents of an Email-type Screen as the email body content.
The Send Email package provides mailer drivers for the following services:
Maintain uniform JSON schemas for all ProcessMaker Platform assets in your organization.
Start with JSON Schema.
Use the Vocabularies package to maintain uniform JSON schemas across all assets in your organization. These assets include Processes, Screens, and Scripts.
Use Vocabularies to enforce compliance with a specific data structure in Request data for your Processes. Apply one or more Vocabularies to your Processes and/or specific BPMN elements in your Process models to ensure the JSON data model in Request data complies with a data structure you need to meet regulatory specifications or ensure Request data contains required information as each Request routes through workflow.
A Vocabulary is a JSON schema designed to annotate and validate ProcessMaker Platform assets to which that Vocabulary is applied. The JSON schema describes your existing data format(s) in both a machine and human readable structure. Any ProcessMaker asset to which that Vocabulary applies must conform to that JSON schema.
Use Vocabularies for the following reasons:
Ensure that data associated with the ProcessMaker Platform asset to which the Vocabulary applies complies with a required data format. For example, use a Vocabulary on a Task element. By extension, the Vocabulary applies to the Screen referenced by that Task element. The Vocabulary ensures that the Screen designer complies with the JSON schema as structured in the Vocabulary. This maintains consistency, validation, and compliance across any Task to which that Vocabulary applies.
Ensure the quality and compliance of submitted data. For example, ensure that information entered into a Screen for a Task complies with a regulatory specification.
The Vocabularies package has the following components after it is installed:
Manage your Vocabularies: Manage your organization's Vocabularies. See .
Set Vocabulary permissions: Determine which users and/or groups have permission to view, create, edit or delete Vocabularies. See .
Start Event element configuration: to a Start Event element.
Intermediate Message Catch Event element configuration:
to an Intermediate Message Catch Event element.
Form Task element configuration: to a Form Task element.
Manual Task element configuration: to a Manual Task element.
Script Task element configuration: to a Script Task element.
Sub Process element configuration: to a Sub process element.
Allow anonymous or authenticated users to start or participate in Requests via a published URL.
Allow anonymous or authenticated users to start or participate in Requests via a published URL.
The Web Entry package has the following components after it is installed:
Persons can start a Request: Web Entry integrates with the to allow either an anonymous or authenticated user to start a Request via a Web Entry. In doing so, specify which the Request starter views when accessing the Web Entry's URL, and whether to display a different Screen or be redirected to another URL when the Request starter starts the Request. Each Start Event element in a Process model can be configured with different settings.
Persons can participate in an in-progress Request: Web Entry integrates with the to allow either an anonymous or authenticated user to participate in an in-progress Request via Web Entry. In doing so, specify which Screen the Task assignee views when accessing the Web Entry's URL, and whether to display a different Screen or be redirected to another URL when the Task assignee submits the Task. Each Form Task element in a Process model can be configured with different settings.
See .
Decision Task connector: Use Decision Task connectors to run Decision Tables in your Processes. Specify which Decision Table(s) to run, thereby evaluating their business rules, and then map how data routes between variables in the Request to and from variables in the Decision Table(s). See for more information.
View translations of the ProcessMaker Platform user interface in German, Spanish, and French languages. Change the labels and messages throughout the ProcessMaker Platform user interface.
The ProcessMaker Platform user interface by default is in English. However, ProcessMaker Platform provides the following translations of the ProcessMaker user interface:
German
Spanish
French
The Translations package displays each label and message in the ProcessMaker Platform user interface in these four languages. For each label or message, the Translations package displays the default English language as well as each non-English language. When the Language setting is changed in user profile or user account, ProcessMaker Platform displays the appropriate labels and messages for that selected language. Changing the Language setting only affects that selected user account.
If the Translations package is not installed, ProcessMaker Platform only displays the default English-language user interface labels and messages. Furthermore, the Language setting in user profiles and user accounts is not available.
Optionally, use the Translations package to edit the labels and messages that display. This may be useful for the following reasons:
Replace ProcessMaker Platform branding with our own: Your organization uses specific branding and/or terminology that you want displayed throughout your ProcessMaker Platform instance. In this regard, you are replacing ProcessMaker Platform's branding with your own.
ProcessMaker Platform is white-labeled: As a ProcessMaker partner using ProcessMaker Platform for your client, your client may want you to white-label ProcessMaker Platform: hide all ProcessMaker Platform branding and terminology and replace it with theirs.
When replacing ProcessMaker Platform branding and/or white-labeling ProcessMaker, customize the colors in the ProcessMaker Platform user interface to show your organization's or client's color palette.
Note that if you edit the default English-language labels and messages, you are responsible for ensuring that the non-English translations match your English-language revisions and are accurate.
See the following topics regarding configuring the language setting in a user profile:
See the following topics regarding white-labeling ProcessMaker Platform:
Comment in Task summaries with other users.
Use the Comments package to discuss Tasks with stakeholders in that Request. Add and reply to comments regarding Tasks for Form Task elements and Manual Task elements in a Process model.
Comments have the following attributes:
Comments are available in Form Task and Manual Task elements, and only if the Process containing that element is configured to use comments and the user or group member has the appropriate Commenting permission to do so. Enter comments into a Task's Screen prior to or while entering information into that Screen.
Comments may also be entered into Conversational-type Screens, though comments must be entered prior to entering information into that Task's Screen.
Comments display in these summaries:
Task summaries: Comments display below the Form tab of Task summaries. After an initial comment is created for a Task, replies to that comment display in chronological order from top to bottom in that comment thread.
Request summaries: Comments display in a Request's history in chronological order from top to bottom intermingled with events in that Request.
Tag users in comments to invite that user into the comment thread so that user can participate in the discussion. Tagged users receive a notification of the comment regardless of whether that user is currently a Request participant: that user automatically becomes a Request participant when tagged in a comment even if that user has not been assigned or participated a Task in that Request.
See the following topics regarding how to configure and use the Comments package:
Process configuration: may be used in Request summaries from a Process.
Request comments: .
Task comments: .
Use reusable and pre-built Process Modeler objects created from a set of other objects to serve a specific purpose or function.
A is a reusable Process Modeler object composed of a set of other objects to serve a specific purpose or function. Process Designers may place into a Process a PM Block as its own Process Modeler object and then configure it as its own functional unit. The Process Modeler need not have the technical skills to have composed the PM Block, but be able to quickly place it into Process models and configure to the business solution.
PM Blocks have the following attributes:
PM Blocks are pre-built, packaged Processes: PM Blocks are ready-to-use, packaged Processes with their own configuration settings designed by the Process Designer who built the PM Block. PM Blocks are no-code to place in Process Modeler.
PM Blocks are reusable: PM Blocks are reusable by any Process Designer with appropriate permissions, and then configured for each business solution. Configuration settings, such as authentication to a third-party service, are separate from the objects within the PM Block. This allows PM Blocks be quickly configured and deployed regardless of technical expertise or the involvement of Administrators.
Built in Process Modeler: PM Blocks are built from Process Modeler, saved as a Process, and then saved as a PM Block. Process Designers can design complex functionality that other Designers may leverage with no technical skills.
Save a Process as a PM Block: Any user with appropriate permissions may save a Process as a PM Block and/or use a PM Block in a Process model.
Built PM Blocks are accessible from Process Modeler for Process design: Within Process Modeler, PM Blocks are available in a separate tab in the left-side panel, adjacent to the ProcessMaker BPMN elements and connectors. With the appropriate permissions, a Process Modeler may place a PM Block as its own object, and then configure it with the configuration settings built for that PM Block.
Establish hierarchy in your organization to be able to escalate Tasks to an assignee's manager, delegate work to another user, and schedule working hours for each user.
Use the Advanced User package to establish managerial and work-delegation relationships within your organization by configuring managers to users and groups. Set working schedules for each user, and configure to whom to delegate work when that user is out of the office or outside of scheduled working hours.
The Advanced User package has the following features:
Configure the manager for each manager and for each group. Form Task elements and Manual Task elements within Process models can then be configured to escalate to the manager for that Task assignee. For example, design a Process such that if the Task assignee does not complete a Task within a day of it being assigned, route that Process to the Task assignee's manager.
Use the Schedule status for each user to set the schedule for each user to be available to work on Tasks. In doing so, set which days of the week and hours of those days in 24-hour format each user is available. The Schedule status becomes that user's status when viewing users in the organization.
Use the Out of Office status for when a user is not available for work, such as when that user takes leave. The Out of Office status becomes that user's status when viewing users in the organization.
Configure for each user to whom to delegate work when that user is not available in the following circumstances:
That user has the Out of Office status: Newly assigned Tasks automatically reassign to the delegated user.
That user has the Scheduled status: Newly assigned Tasks automatically reassign to the delegated user when the initial Task assignee is not scheduled to work.
Select a Process Manager for each Process. The Process Manager understands the Process design and workflow dynamics to troubleshoot Request routing incidents. This user is assigned Tasks in that Process's Requests in which workflow would otherwise pause indefinitely when that Request's workflow cannot continue to a valid Task assignee for any of the following reasons:
The Request routes to a Task assignee whose user account is inactive.
The Request routes to the Task assignee's manager, but that user's account is not configured with a manager.
The Task assignee does not have a user account manager, and is a member of two or more groups which have different managers.
The Request routes to a Task assignee in which that user's account is set with the following statuses:
The user's account is set to Out of Office status, but not configured with a delegated user to assign new Tasks while with this status.
The user's account is set to Scheduled status, is not scheduled to work when the Task is assigned, and is not configured with a delegated user to assign new Tasks.
The Process Manager is assigned the Task in that Request, and may then indicate how to route that Request. The Process Manager may optionally cancel that Request if that user is among those selected to do so.
Assign a Task to the Process Manager when configuring Form Task elements and Manual Task elements.
Configure Form Task elements and Manual Task elements to escalate a Task to the Task assignee's manager.
Configure Form Task elements and Manual Task elements to allow a Task assignee to escalate the current Task to her or his manager.
Enable User Signals to broadcast Signals for specific user events. When a user account is created, deleted, read, and/or updated, optionally broadcast a Signal of that event. Signal-type BPMN 2.0 elements listening for Signal events in your Process models can then trigger. For example, each time a user account is created, enable the Create user Signal to trigger a Signal Start Event element in a Process model that starts a Request to onboard a new employee in your organization.
Add user extended properties to become settings in all user accounts. For example, to add user extended properties labeled "Employee ID" and "Hire Date" to enter each employee's ID number and hire date.
See the following topics regarding how to use the Advanced User package:
Configure user settings: for that user's manager, delegated user, and schedule.
Configure the manager for a group: for that group's manager.
Form Task element assignment options: .
Manual Task element assignment options: .
Set User Signal settings: .
Set user extended properties: .
Allows the user to include a personalized signature on a Screen.
Use the Signature package to include a digital signature within a created form in Screens.
This digital signature package is available providing the user has access to screen sensitivity. After the signature is produced, it is possible to save it in order to be used in further instances.
Please note that it is possible to Redo the signature entered using the Redo button.
When the changes are satisfactory select the Save button.
See .
Manage and maintain multiple versions of your Processes, Screens and Scripts.
Use the Versioning package to manage and maintain multiple versions of your Processes, Scripts and Screens. A version is a set of changes made to a ProcessMaker Platform asset at a particular time by a Process Designer. Versioning maintains a record of all named and unnamed changes to that asset. Versioning information is useful both for auditing and historical data maintenance purposes. The saved versions display in a tabular format when viewing version history for an asset from where they can be edited and/or marked as the Current Version according to your business needs.
The latest saved version of a ProcessMaker Platform asset is automatically designated as the current version and is used in new Requests. Version changes are not reflected in Requests which were in-progress or already completed when that asset version changed.
The Versioning package has the following attributes:
When the Versioning package is installed, versioning is available for Processes, Scripts and Screens.
Every new version is saved with the following information:
Date: The date and time when a Process Designer saved that version.
Name: The name of this version as entered by a Process Designer.
Description: A description of the changes in this version as entered by a Process Designer.
Saved by: The name of the Process Designer who saved this version.
Although multiple versions of each ProcessMaker Platform asset can be saved, only one version can be marked as the current version.
Any existing version of a ProcessMaker Platform asset can become the current version when configuring that asset.
See the following topics regarding how to use versioning in Processes:
Save a version: of a Process in the Process Modeler.
View and configure Version History: of a Process in Process Modeler.
See the following topics regarding how to use versioning in Scripts:
See the following topics regarding how to use versioning in Screens:
Save a version: of a Script in the Script Editor.
View and configure Version History: of a Script in Script Editor.
Save a version: of a Screen in the Screen Builder.
View and configure Version History: of a Screen in Screen Builder.
Send automatic notifications to Slack channels during Requests.
Use the Slack Notification package to automatically send Slack notifications to a selected Slack channel during your Process Requests.
After the Slack Notification package is installed, the Slack Notification connector integrates into Process Modeler. Use the connector in your Process models as you would BPMN elements: drag and place the Slack Notification connector into your Process model, configure its settings, and then add its incoming and outgoing Sequence Flow elements.
Before using the Slack Notification connector in your Process models, your ProcessMaker Platform instance must be granted access to your Slack workspace by building a Slack App. Ask your Slack administrator to help you with the following:
Save and share search queries associated with Requests and Tasks.
Use the Saved Searches package to save and share search parameters associated with Requests, Tasks and Collections. In doing so, you manage the search parameters for your Saved Searches. You may share your own Saved Searches with other users and/or groups. Recipients of your shared Saved Searches can only use your Saved Search to view its search results, but cannot modify your Saved Searches' parameter settings you configured. The name for a Saved Search does not need to be unique within your ProcessMaker Platform instance. Therefore, multiple Saved Searches may have the same name when your own Saved Search and one shared with you have the same name.
Similar to advanced Request searches, advanced Task searches, and Collection record searches, filter the data that for a Saved Search using ProcessMaker Query Language (PMQL).
Charts help visualize your Saved Search results. Though you can customize in tabular format the data details for your Saved Searches, nothing distills that data like a customized chart. Create and configure two-dimensional charts to visualize Saved Search results after selecting a Saved Search. You may create customized charts regardless of whether you created the Saved Search or if it was shared with you.
Charts use the data results from the Saved Search to visualize those results in a variety of chart types and styles. Chart data may be filtered by using an optional PMQL query that further filters the data from that Saved Search to visualize minute data.
Screen designers may also embed Saved Search charts into Form- and Display-type Screens using the Saved Search Chart control.
You may schedule a regular interval in which to email reports for either your own Saved Searches or those shared with you. See .
The Charts tab displays charts created for a Saved Search. See .
See .
