Position Group
A position group object is an object that is used when multiple people want to be subjected to actions in flow steps. While only one user or position can be added to the position object, multiple users, positions, user groups, departments, or title-based users can be added to the position group object.
When the flow arrives at the Position Group object, a confirmation email is sent to everyone in the group, and users in the group can access this process log from the Approvals screen on their web interface page.
The contents of the Position Group object can be statically exported at design time, or the group content can be populated with code. When the object in the Flow design screen is clicked, the object properties appear in the Property Viewer panel.
When the position group object is clicked, there are "Appearance", "Properties" and "Events" tabs in the Property Viewer panel.
Appearance
Text Configs
'Object Name' - The name of the object to be used on the system side. On the code side, the object is accessed by the value that is written in the object name field.
'Caption' - The area where the object's title text is entered.
'Is Lock' - This field is activated if the object is not to be moved at the time of design.
'Size' - The part where the width and height of the object are adjusted.
Properties
Group Content
'Group Content' - This field fills in the content of the Position Group object. Clicking on the group content area will open a screen with the "Contents" button to select the contacts to be added to the Position Group, the "Create" button to create the selected contacts in the object, and the "Delete" button to remove the added records from the group.
Pressing the "Contents" button will open the selection area where it will be indicated which type of content will be added to the Position Group. Area; There are 3 options listed as Position, Position groups and Object on document.
{#members-position} if position selection is made
When the position option is selected, a new pop-up will open and in this field; The Fixed Position, User, Variable Position, and Flow Initiator options are listed.
- When the fixed position option is selected, the screen will list all the position records available in the system. Selecting one or more position records from this list and pressing the "Create" button adds the selected position records to the Position Group object. If the developer wishes, he can continue to fill in the field content by pressing the "Contents" button again.
- When the user option is selected, the screen will list all the user records present in the system. Selecting one or more user records from this list and pressing the "Create" button adds the selected users to the Position Group object. If the developer wishes, they can continue to fill in the group content by pressing the "Contents" button again.
- When the variable position option is selected, the screen lists all the Position objects and the Flow Initiator object that are present in the flow design. If you want to add a person or position in the flow to the Position Group object, the Position objects that represent that person or position are selected from this field. After pressing the "Create" button, the developer can continue to fill in the group content by pressing the "Contents" button again if he wishes.
- Selecting the Initiator of Flow option adds the user who initiated the flow to the Position Group. If the developer wishes, they can continue to fill in the group content by pressing the "Contents" button again.
{#members-position-groups} if selecting position groups
Selecting the Position Groups option within the Group Content area in the Position Group object opens a new pop-up and in this field; The options Document approvers/rejectionists, User group by title, User group by department, and User groups are listed.
- The document approvers/rejectionists option is the option used in the corresponding flow design to add whoever took action until the flow reached the Position Group object. If the developer wishes, they can continue to fill in the group content by pressing the "Contents" button again.
- User group by title option is the option to add users with a specific title definition to the Position Group object. Selecting this option from the "Contents" area lists all the title records defined in the system.
According to the selection made in the screenshot below, it means that users with the title "Project Manager" will be added. If the developer wishes, they can continue to fill in the group content by pressing the "Contents" button again.
- The User group by department option is the option used to add users in a specific business unit to the Position Group object. Selecting this option from the "Contents" area lists all the department records defined in the system.
According to the selection made in the screenshot below, it means that the users in the "Product Management" department will be added to the Position Group object. If the developer wishes, they can continue to fill in the group content by pressing the "Contents" button again.
- When the user groups option is selected, the screen will list the User Groups defined under the Human Resources heading in the user interface. When the developer selects a user group from this list, the users defined in the selected user group are added to the Position Group object. When new users are added to or removed from the relevant user group from the Human Resources department, the flow to the Position Group object from which this user group was selected is sent for approval to the people in the user group in its last updated form.
{#members-documents} if the object selection on the document is made
- Used to add users or positions selected in a DataGrid object on the form to the Position Group object when the On-document object option is selected. The process of adding people in the field can be made position-based or user-based.
If the contacts selected in the DataGrid object on the form are to be added to the field on a per-user basis, the table objects must have an ID column that contains the "User Name (registration number)".
If the people selected in the DataGrid object on the form are to be added to the field based on position, the table objects must have an ID column that contains the "Position id" information.
When the "Object on document" option is selected from the Contents area, the following fields will appear on the screen;
Feature | Description |
---|---|
Document | This area lists all the Document objects that are included in the flow design. If the data of the DataGrid object on the form is intended to be accessed, the Document object in which that form is defined is selected from this field. |
Data type | The "User" and "Position" options will be listed. If the records to be added to the Position Group field are to be added on a per-user basis, "User" should be selected from this field, and "Position" option should be selected from this field if they are to be added on a position-based basis. |
Table / Details | Whichever DataGrid object on the form is inserted in the Documents field will be added to the Position Group object, the corresponding object is selected. |
Field | This area lists the columns of the DataGrid object. If "User" is selected as the data type, the column containing the user IDs should be selected in this field. If "Position" is selected as the data type, the column containing the position IDs should be selected in this field. |
Documents
'Documents' - This field sets which form and which view of the form the user in the Position Group object can see. The forms included in the project are kept in the Document object on the flow side. The document object represents the form that is linked to it and the data on the form. A flow can have multiple, different Document objects that represent different forms. If the user in the Position Group object is asked to see which form, this field selects the Document object to which the corresponding form is linked and determines its necessary settings.
More than one Document object can also be added to the user defined in the Position Group object for viewing in the web interface. When clicking on the Documents section, one or more Document objects that the user wants to see are added with the "Insert" button and the settings of the edits that can be made on the document are determined.
Properties tab properties
Feature | Description |
---|---|
Document | The area on the flow design where all Document objects are listed. The Document object to which the form to be shown to the person in the Position Group object is linked is selected from this field. |
View | The views of the form to which the Document object selected from the "Document" field is linked are listed in this field. When the user in the Position Group opens the form, the form view that he is asked to see must be selected from this field. If no selection is made from the view area, the user will see the "default" view. |
Panel Size | It is the area that determines the width at which the document object defined in the web interface can be opened. Selecting one of the 1-2-3 values will open the panel size at the selected value width. |
Editable | This field determines whether users in the Position Group object can edit the document. A document without the Edit field checked opens to the user in read-only mode in the web interface, and the contact can't edit the form. If editing is desired on the form, this field must be checked. |
Show events | This is the area where the user in that step is set to see event buttons on the form that they will take action to advance the form and continue the flow. If the user needs to use the action buttons to act on the relevant document and include it in a workflow, this field should be checked. If the document is attached to the user for informational purposes, the action event buttons do not need to appear in this document and in this case the "Show events" field should not be checked. |
Signature | The system supports digital signature infrastructure. If certificates have been obtained from digital signature providers, this option can be used for signed approvals of workflows and documents.The signature field lists 4 options;< br/> No sign : Selected< br/> to indicate that no digital signature will be used on the document Optional : Optionally selected when using a digital signature on the document. When the process comes to the user in question, it is up to the user whether the document is digitally signed or not.< br/> Required : Requires the user to sign the document with a digital signature certificate, regardless of whether they have a certificate or not.< br/> Required if possible : If a digital signing certificate exists for the user, the system forces the user to use the digital signing certificate to approve the document. The requirement applies to the user only if a specific certificate exists. |
Signature tab properties
This is the part where detailed edits to the document signing settings are made.
Feature | Description |
---|---|
Signature | An area that determines whether the document is signed using CAdES or PAdES types. |
Timestamp | It is the feature that is activated when you want to use the time denga when signing the document. |
:::d anger WARNING
If the document object inserted within the object has a signature set, the document object to be signed must contain documents (pdf etc.) and signatures must be placed on the documents. CSP forms cannot be signed!
:::
CAUTION
If the signature setting has been made on the document object inserted within the object, the Digital Signature Required selection in the event must be activated in the event in which the signature operation will be performed in the Events section of the same object attached in order for the signature process to be initiated in the web interface.
Message
'Send Mail' - When the flow step falls on the corresponding Position Group object, the system automatically sends an e-mail to the person in the object informing them that a process has been reduced to their approval. If mail is not requested to be sent when action drops on the corresponding object, the Send Mail field can be unchecked. This is typically used to avoid sending mail to people in test flow scenario trials.
TIP
In addition to turning off email sending by navigating through objects, it is also possible to block email sending across the flow. Email sending can be turned off across the flow by activating the Disable Email Sending feature in Flow Properties>
-General.
'Caption' - The header of the confirmation email to be sent to users in the Position Group object. The header information includes the "ProcessCaption", "FirstName", and "LastName" parameters that come by default. These parameters are the system's own parameters and the title of the process to which the mail is sent, the name and surname of the person to whom the mail is sent are automatically filled in by the system. The mail header structure that comes by default is as follows. The developer can change the title of this mail if he wishes.
>
Bimser Synergy {{ProcessCaption}} confirmation ({{FirstName}} {{LastName}})
'Message' - The message text part of the mail to be sent to the users in the Position Group object is located in this field. By default, the incoming message text can be changed optionally.
'Attachments' - defined from this field if an attachment file is desired to be sent in the mail to be sent to the users in the Position Group object.
Clicking on the Atttachments field opens the screen where it will be defined to select the type of attachment that is desired to be added to the e-mail to be sent.
In the Attachments edit window, the **"Add" button can be used to define the attachment to be added to the e-mail to be sent to the contact in the Position Group object, change the attachment settings by clicking on the line in the made definition, or press the trash can icon that appears in the attachment line details and remove the event from the object.
- The Type field is the field where the attachment file is located. DM, Flow, RelatedDocuments can be selected.
- Selecting Type:DM makes the selection in Document Management within the Value field in the panel.
- When Type:Flow is selected, the object containing the Id of the file to be added as an attachment can be selected as liquid or static data can be written. ({{ Document1.DocumentId }}, {{ Variable1.Value }}, 56669)
- When Type:RelatedDocuments is selected, the Document field appears to select the Document object containing the form containing the RelatedDocuments object to use. Selecting indicates that the Related Documents field appears in the panel and lists the Related Documents objects within the selected object.
'Edit Message Source' - This feature is activated if the message to be sent to the contacts in the Position Group object is intended to be sent as a customized message template and not as the system default. When the feature is activated, the area named "Source Message" will be visible.
'Source Message' - The screen that allows the default mail template to be displayed in html format and modified is opened from this area. The designed mail template can be viewed instantly in the preview window.
If you want to edit a certain language in the e-mail, the language option in the panel can be changed and the e-mail codes and preview of the selected language can be made.
INFO
The language in which users receive e-mail in the system is determined by the selection made in the Default Language field in each user in the Human Resources section.
<
div style={{textAlign: 'center'}}>
<
/div>
Push Notification
CAUTION
Push Notification is sent via the mobile application to the devices of the person/persons who have logged in to the Bimser Synergy CSP application and have given permission to the notifications.
'Send Push Notification' - If you want to send notifications on the mobile device of the people in the Position Group object, the field is activated.
'Caption' - The header information of the mobile notification to be sent to the contacts in the Position Group object. The header information includes the "ProcessCaption", "FirstName", and "LastName" parameters that come by default. These parameters are the system's own parameters and the title of the process to which the information is sent, the name and surname of the person to whom the e-mail is sent are automatically filled in by the system. The mail header structure that comes by default is as follows. The developer can change the title of this mail if he wishes.
>
Bimser Synergy {{ProcessCaption}} confirmation ({{FirstName}} {{LastName}})
'Message' - The text part of the informational message to be sent to the person in the Position Group object is located in this field. By default, the incoming message text can be changed optionally.
Flow Control
'Empty Group Event' - If no records are returned from the query for a group object populated with code, the user group defined to the group is empty, or the group content remains empty with any other scenario, the flow is automatically escalated from the group object to the event arrow arm selected in this field so that the system does not receive the "Group Empty" error when the flow arrives at the Position Group object. The purpose here is flow; When the group content is empty, it is the default to resume it by allowing it to advance from the selected event arm.
This area lists the events that were added to the Position Group object from the Events area. When the group is empty, the corresponding event must be selected from whichever event branch of the flow is desired to proceed. When the Position Group object is dragged to the flow design screen, the "Approve" and "Reject" events are attached by default. Therefore, if no changes are made, the "Confirm" and "Reject" events are listed in this field as well.
CAUTION
When the events defined on the Position Group object are modified, the event selected in the "Empty Group Event" field must also be modified by selecting one of the existing defined events.
For example; The "Confirm" event has been added to the Position Group object, and the "Approve" option has been selected from the "Empty Group Event" field. The developer removed the "Confirm" event from the group and replaced it with the "Submit" event. In this case, the "Approve" event, which is still the deleted event, will be left in the "Empty Group Event" field and will give an error when the process reaches this step. An event removed from the Events area must also be removed from the "Empty Group Event" field, and a selection of an existing event must be made in this field.
'Conflict State Event' - "Majority" is selected as a condition for the progress of the process in the Position Group. Here; If the majority of the people in the group agree, the flow is asked to move forward. If it is considered that there are 4 people in the group and 2 people approve and 2 people reject it, the majority requirement will not be met and the flow will remain unstable.
As another scenario, the condition of progress of the process in the Position Group is selected as "All". If all the people in the group agree, the flow is asked to move forward. However, when even 1 person from the group presses the reject event, the flow will still not be able to progress, the progress condition will not be met and an unstable situation will occur.
In such conflict situations, a default event is selected from the "Conflict State Event" field so that the flow does not hang or fail, and when such instability occurs in the group, the flow proceeds through the selected event arm.
CAUTION
When the events defined on the Position Group object are modified, the event selected in the "Conflict State Event" field must also be modified by selecting one of the existing defined events.
For example; The "Confirm" event has been added to the Position Group object, and the "Approve" option has been selected in the "Conflict State Event" field. The developer removed the "Confirm" event from the group and replaced it with the "Submit" event. In this case, the "Conflict: State Event" field will still have the "Confirm" event left, which is the deleted event, and will give an error when the process reaches this step. An event removed from the Events area must also be removed from the "Conflict State Event" field, and a selection of an existing event must be made in this field.
'If Processed Before Do Not Send Request' - According to the flow scenario, in some cases the stream may be resent to a person who is transacting. In such cases, it may be desirable to continue the process without the user having to take action again.
To illustrate the situation with an example, in a designed Workflow, the user is asked to go to the approval of the HR manager after the approval of the manager. In such a scenario, when a staff member from the HR department starts the business process, the HR manager will already approve the process as the manager, so the document will come to him again and he will have to approve the same document a second time. In order to avoid such scenarios, the "If Processed Before Do Not Send Request" option is used.
When the "If Processed Before Do Not Send Request" option is activated, the new control fields "Before Processed Events" and "If Document(s) is/are Changed Then Request is Needed" will be visible.
'Before Processed Events' - If the user has already consented with one of the events defined on the field, it allows the process to be automatically confirmed by selecting the relevant event in the field.
For example, in a designed Workflow, the user is asked to go to the HR manager approval after the manager approval, and both objects have the "Approve Permission Request" event. In such a scenario, when a staff member from the HR department starts the business process, the document will come to him again as the HR manager will approve the process. However, the process will continue automatically because the "Approve Permission Request" event is attached to the field and the HR manager has already given approval using this event beforehand.
TIP
If Processed Before Do Not Send Request and Before Processed Events work if the user has previously used the process-defined event.
CAUTION
Once the If Processed Before Do Not Send Request feature is executed, code can be written at the API level (by accessing the object property in the stream) to reactivate it.
'If Document(s) is/are Changed Then Request is Needed' - Let's elaborate a little more on our previous scenario and assume that there is another position approval between the manager approval and the HR manager approval. When the HR staff fills out the document, it will first go to the manager – where the manager becomes the HR manager – and then to the approval of the other Position involved in the work process. After the other position approval, the process will be completed without visiting the HR manager again due to the "If Processed Before Do Not Send Request" option. However, if the Position Group object in our scenario has made any changes to the document, that is, if the document has become different from the initial approval of the HR manager, the process will be completed before the HR manager sees this document a second time. As a second option to eliminate such situations, the "If Document(s) is/are Changed Then Request is Needed" option has been added to the system. Thus, using this option, the relevant document can be made to go back to the HR manager in the scenario described above.
Events
'Events' - This is the part where the action events that the Position Group member can take for the form in the web interface are defined. The events defined in this field appear as action buttons on the form in the web interface. Whichever event button the user clicks, the process proceeds to the flow step where the connection arrow for that event is connected at the moment of design.
If the number of events has been added to the object from the Events area, the connection arrows to represent each event must be extracted from the object in the flow design screen, and these arrows must be connected to wherever the stream is intended to go when the corresponding event is clicked.
Clicking on the Events field will open a window where events to be added to the object can be selected and edits can be made for those events. Here the events defined in the Flow Properties->
Events** tab are listed as event records. By default, the Position Group object comes with "Approve" and "Reject" events attached. To modify existing events, add a new event, or remove an existing event from the object, clicking the Events field opens the event editing window.
A new event can be added to the Position Group object with the "Add" button in the Events editing window, the event settings can be changed by clicking on the event line for attached events, or the event can be removed from the object by pressing the trash can icon that appears when the attached event line is reached.
Feature | Description |
---|---|
Identity | The id value that represents the event appears in this section. This field is in read-only mode and cannot be changed. |
Description | The area where the text portion of the event appears. |
Visible | This feature must be activated in order for the corresponding event button to appear in the web interface. |
Validate | In order to work with the mandatory conditions given in the object properties at the time of form design and the controls written in the validation Rule Manager section of the form, and to give a warning message to the user in cases where the desired condition is not met or the mandatory objects are left empty, the "Validate" field must be checked on the event button clicked by the user. |
Reason | When an event with a reason field marked is clicked on in the web interface, a field is removed for the user to enter a description of the reason. It is typically used for the Reject event, and when the person wants to reject the form by pressing the Reject button, they are prompted to enter the reason for the rejection in the reason field. |
Reason Title | The field where the reason description is shown in the web interface is the field where the expression in the header is customized. |
Digital Signature Required | Clicking on an event in the web interface with the digital signature required field marked will open the screen required for the user to perform the E-signature process. For the signing process to begin, the Signature settings must be set on the document object defined in the object. |
Form | From the form field, all the Document objects that are in the flow are listed. When a Document object is selected from this field for any event, clicking on this event in the web interface opens the screen of the defined form within the Document object selected from the Form field in front of the user and the user is expected to fill in the fields in the form. When the user fills out the form that opens and says OK, the flow proceeds to the next step. This completed form becomes the "Event Form" of the corresponding flow object. |
Icon | The icons of the event buttons that will appear on the form in the web interface are selected from this area. By default, the icons of the incoming events in the system are automatically specified in the icon column. |
Condition | This field is the field in which the condition on which the progress of the flow from that event depends is selected for each event. As an option in the Condition field; All, Number, Majority, Percentage are listed.< br/>``````< br/> All : All is expected to click on the action event with "All" selected in the Condition field for the flow to the position group object to proceed.< br/> For example; If the "Confirm" event has been added as an event to the Position Group and "All" has been selected from the Condition field, all of the group members must have pressed the "Confirm" button for the flow to proceed. If "All" is selected from the Condition field, the "Condition Value" field is not shown.< br/>``````< br/> Number : Used when it is sufficient to take the specified number of related event actions in order for the flow to the position group object to proceed.< br/> For example; If the "Confirm" event is added as an event to the Position Group and "Number" is selected from the Condition field, it is sufficient for the number of group members written in the "Condition Value" field to press the "Confirm" button for the flow to progress. If it is desired to perform an operation such as it is sufficient for only 1 person from a group of 5 people to give approval, "Number" should be selected from the Condition field and 1 should be written in the Condition Value field. So when 1 person from the group hits the Confirm button, the flow doesn't wait for other group members to take action, it removes pending work on other group members and advances the process to the next step.< br/>``````< br/> Percentage: For the flow to the position group object to proceed, a certain percentage of group members must have taken the appropriate action.< br/> For example; If the "Confirm" event is added as an event to the Position Group and "Percentage" is selected from the Condition field, it is sufficient for the group member to press the "Confirm" button to press the "Confirm" button for the group member to proceed with the flow as a percentage of the number typed in the "Condition Value" field (if 30 is written in the Condition Value field, it means that 30% of the group has taken action).< br/>``````< br/> Majority : For the flow to the position group object to proceed, the majority of group members must have received the corresponding action event. Here, the system is automatically based on 51%. The "Condition Value" field does not appear. |
CAUTION
If the settings for an event that was added to the object context were changed in Flow Properties->
Events, the attached event record in the object context might not be affected by this change. After the change, objects that use the corresponding event may need to be checked and the event for which the change was made may need to be removed and re-added from the Events area.
CAUTION
If an event attached to an object is deleted from the Flow Properties->
Events area, the corresponding attached event record within the object must also be deleted, checking for objects that use that event.
Options
'Hide the Approver' - Feature that allows you to show the name of the user in the position in the flow history as hidden as * * * *.
'Show in the Flow History' - This is where it is set whether the corresponding flow step is shown in the flow history or not.
Time Out
This section uses it to add a time-out action to the Position Group object. When the flow falls on the position object, within a certain period of time, if the person in the position has not taken any action, the request times out and it is desired from anywhere in the flow to continue the operation, the parts contained in this section are filled. If the fields in the Timeout section are full and the "Timeout" link has been removed from the Position Group object, the request times out at the end of the specified time and the flow proceeds from where the "Timeout" lever is connected.
'Day' - If the expected action on the Position Group object is intended to time out at the end of a certain day, the timeout day information is written in this field.
'Hour' - If the expected action on the Position Group object is intended to time out at the end of a certain hour, the timeout time information is written in this field.
'Minute' - If the expected action on the Position Group object is intended to time out after a certain minute, the timeout minute information is written in this field.
'Calculate Using Working Hours' - This field is checked to run the timeout period by calculating the working hours defined in the system.
'Calculate Using Holidays' - This field is checked to run the timeout period by calculating the holidays defined in the system.
INFO
It is checked by the system that the attached properties on the object are correct. When a missing feature is found, a red exclamation point icon can be displayed on the object, and hovering over the icon with the mouse pointer can display what is missing or incorrect.
Events
The events owned by the Position Group object are located in the "Events" tab in the Property Viewer panel. Each event is triggered at different runtime moments, performing its own unique operations. Code written by the developer to these events is also executed at the time the corresponding event is triggered. To write code for any event, double-click the appropriate event line from the Events tab. The screen is directed to the flow code editor section named "FlowName.cs" and the method block for the clicked event is automatically created. The developer can construct any code block he wants in this method. Next to the event whose method is created on the code side by clicking from the Events tab, the method name information is automatically generated and the relationship between the event and the method is specified.