Stream starter
The Flow Initiator object is the flow object that represents the person who started the process when a process is started from the web interface or by code.
:::d anger WARNING
The Stream Initiator object is an object that was used in the old flow template. The new flow template is created using the Flow Start, Flow End, and Document objects.
> New flow template
> Old flow template
In the new flow template, there is no record over the database because the document will not be created until the process is started. Clicking on the menu in the old template creates a record in the database because it will pass through the Create Document object.
:::
In this flow template, the Flow Initiator object is positioned after the Start Flow and Create Document objects. The purpose of this design is to ensure that a process initiated by clicking on the project node attached to the menu from the web interface is designated as the Flow Initiator as the person who triggers the process.
CAUTION
When the Flow Initiator object is used, the user who started the flow is unable to save the process to Drafts.
The object that initiates the stream should only be used once at the beginning of the stream, and the fallback arrow should not be bound to this object later in the flow. If, after that, the process needs to go back to the initiator of the flow, or if the process steps will go back to the person who started the flow, the Position object should be placed in the corresponding step, not the Flow Initiator object, and "Flow Initiator" should be selected as the value in the position object.
When the object in the Flow design screen is clicked, the object properties appear in the Property Viewer panel.
When clicking on the object that starts the stream, 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
Documents
'Documents' - This field sets which form and which view of the form the user who started the flow 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 object that initiates the flow is asked to see, this field selects the Document object to which the corresponding form is linked and determines its necessary settings.
The Flow Initiator object can also add multiple Document objects for the user who started the process to see 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 that is intended to be shown to the person in the position 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 opens the form, the form view that he is asked to see should 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 the user who initiated the flow 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.
Events
'Events' - This is the part where the action events that the user who started the flow can receive 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 Stream initiator object comes with the "Send" and "Cancel" 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 Stream initiator 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 in the attached event line details.
| 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. |
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' - A feature that allows you to show the name of the user who started the stream as hidden in the flow history as * * * *.
'Auto Open Approval Option' - If consecutive flow steps are coming to the same person according to the flow scenario, when the person opens the form for the first action step and presses the action button by performing the necessary actions, the screen will be informed that "Workflow has come to you again". If "Auto Open" is selected in the "Auto Open Approval Option", the form opens directly in front of the user for the second action when the user takes the first action. If "Auto-power" is selected, the screen will redirect to the flow history page after the first action step. To take the second action, the person will need to go to the Approvals page to find the relevant process and reopen the form.
'Show in the Flow History' - This is where it is set whether the corresponding flow step is shown in the flow history or not.
Message
'Send Mail' - When the Flow step falls on the corresponding Flow initiator object, the system automatically sends an e-mail to the person in the object informing them that a process has been dropped for 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 information of the confirmation mail to be sent to the initiator of the stream. 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 initiator of the stream 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 initiator of the flow.
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 Flow initiator object, the attachment settings can be changed by clicking on the line in the made definition, or the event can be removed from the object by pressing the trash can icon that appears in the attachment line details.
- 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 initiator of the stream 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 a notification on the mobile device of the person who started the flow, the field is activated.
'Caption' - The header of the mobile notification to be sent to the initiator of the stream. 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 informative message to be sent to the initiator of the flow is located in this field. By default, the incoming message text can be changed optionally.
Flow Control
'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 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.
Time Out
This section uses it to add a time-out action to the object. When the flow falls on the object, within a certain period of time, if the person in the position has not taken any action, the request times out and from any point in the flow, the process is asked to continue, the parts contained in this section are filled. If the fields in the Time Out section are full and the "Time Out" link is removed from the object, the request times out at the end of the specified time and the flow proceeds from where the "Time Out" arm is connected.
'Day' - If the expected action of the 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 of the 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 of the 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.
Events
The events owned by the object that started the stream 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 indicated.