Routing workflows by employee roles in Worklite Docs for MS Sharepoint 2013 Electronic Document Management
By themselves, the workflows embedded in Sharepoint are a universal tool that can be used in a huge number of variations and in its basic form can satisfy a huge amount of the company's needs in terms of passing a document or task from the initiator to coordinators or approvers (or just any responsible persons) . parallelism or sequence of the process also sufficiently expands the range of possibilities in terms of interconnection of business processes within the company.
Another point is that - in the basic version, Sharepoint does not take into account two fundamental points (about them below), which, in my opinion, are cornerstones in the full sense of both the setting of tasks and electronic document management and require either immediate customization (after purchasing licenses Microsoft, or purchase a pre-finished configuration of functionality.
1. By default, Sharepoint uses not the role participation of an employee, but his account which is not associated with the business process in terms of its role (position) in the company. On the surface, this is not a problem and in general everything is in order. On the other hand, it imposes huge limitations and inconveniences with a detailed understanding of the organizational structure of the organization.
')
Suppose, in the simplest example, we (user A) are the initiator of the task and send it for execution, approval, approval (user B). Everything is great - the task comes. Notification sent. User B - performs the task and everything is fine. But all this magnificence is good - only if a person of 10-20 works in the company and everyone knows each other visually, and even by name. But if the company has employees of 900 commercials hanging around the balance, and then a couple of thousands? .. And I have no idea what their name is, but like any office front fighter, on an intuitive office level, I perfectly understand what logical positions are and who is above and below me. Especially if the employee got sick, quit, died, or just went to countries with more attractive climatic conditions. Therefore, I do not have to know the names, I have enough space under the helmet - just represent what the posts are. It is incomparably easier and more convenient.
It is clear that at the moment we are considering an example on a primitive scale and do not take such things as replacement and delegation of rights, they are wonderful help, but they do not solve the main issue - customization of the system in terms of associating employees with their role (position).
With a role structure, I can always filter by department, branch, or department and choose the position (employee's role in the company) of the employee - from which something is required of me or which requires something from me. The fact is that according to the standard logic of the base system - I am obliged to know everyone by name, but in real life this is not the case. Therefore, one of the main points of primary customization is precisely the combination of accounting with a role in the organizational structure of the company.
2. The second underwater stone is the absence in Sharepoint of any intelligible system for constructing a process route in a particular moment by some simple means that any user can understand. Needless to say, Sharepoint Designer and Visual Studio is an unshakable stronghold with which you can do anything. But we are talking about the simple operators of the system ... Therefore, either the option with the preset process route setting is left, or third-party constructors are selling Nintex (literally everything can, except that it does not clean the potatoes, but it is godless, and requires serious building skills), or the use of very simple routes, something like from point A to point B. Well, in general, is not the point.
Here we implemented a router that is fairly simple, in general, of course, does not allow building large branched processes, but still facilitated the work on building routes both dynamically (that is, what I need, so that he would run just now), and statically (we build in advance chains and save - then just choose from the list.
That is, functionally - it works quite simply:
Having started the document approval process, the employee indicates the approval period, and also selects one of the pre-designed document approval routes.
Further indicates the stages of passage and employees (selects filters from role-based participation in the company, and the system already substitutes its pro-associated accounting)
Next - expose all the required steps and start the process.
Full size here
And all - the process ran! Simple and beautiful :) If the route is one of the permanent - you can not fill it every time, but simply save. And if something new is required, we specify it dynamically with changes.
The product Worklite Docs and Worklite Portal for example - you can look here as an example where electronic document management and corporate portal are presented.
Another point is that - in the basic version, Sharepoint does not take into account two fundamental points (about them below), which, in my opinion, are cornerstones in the full sense of both the setting of tasks and electronic document management and require either immediate customization (after purchasing licenses Microsoft, or purchase a pre-finished configuration of functionality.
1. By default, Sharepoint uses not the role participation of an employee, but his account which is not associated with the business process in terms of its role (position) in the company. On the surface, this is not a problem and in general everything is in order. On the other hand, it imposes huge limitations and inconveniences with a detailed understanding of the organizational structure of the organization.
')
Suppose, in the simplest example, we (user A) are the initiator of the task and send it for execution, approval, approval (user B). Everything is great - the task comes. Notification sent. User B - performs the task and everything is fine. But all this magnificence is good - only if a person of 10-20 works in the company and everyone knows each other visually, and even by name. But if the company has employees of 900 commercials hanging around the balance, and then a couple of thousands? .. And I have no idea what their name is, but like any office front fighter, on an intuitive office level, I perfectly understand what logical positions are and who is above and below me. Especially if the employee got sick, quit, died, or just went to countries with more attractive climatic conditions. Therefore, I do not have to know the names, I have enough space under the helmet - just represent what the posts are. It is incomparably easier and more convenient.
It is clear that at the moment we are considering an example on a primitive scale and do not take such things as replacement and delegation of rights, they are wonderful help, but they do not solve the main issue - customization of the system in terms of associating employees with their role (position).
With a role structure, I can always filter by department, branch, or department and choose the position (employee's role in the company) of the employee - from which something is required of me or which requires something from me. The fact is that according to the standard logic of the base system - I am obliged to know everyone by name, but in real life this is not the case. Therefore, one of the main points of primary customization is precisely the combination of accounting with a role in the organizational structure of the company.
2. The second underwater stone is the absence in Sharepoint of any intelligible system for constructing a process route in a particular moment by some simple means that any user can understand. Needless to say, Sharepoint Designer and Visual Studio is an unshakable stronghold with which you can do anything. But we are talking about the simple operators of the system ... Therefore, either the option with the preset process route setting is left, or third-party constructors are selling Nintex (literally everything can, except that it does not clean the potatoes, but it is godless, and requires serious building skills), or the use of very simple routes, something like from point A to point B. Well, in general, is not the point.
Here we implemented a router that is fairly simple, in general, of course, does not allow building large branched processes, but still facilitated the work on building routes both dynamically (that is, what I need, so that he would run just now), and statically (we build in advance chains and save - then just choose from the list.
That is, functionally - it works quite simply:
Having started the document approval process, the employee indicates the approval period, and also selects one of the pre-designed document approval routes.
Further indicates the stages of passage and employees (selects filters from role-based participation in the company, and the system already substitutes its pro-associated accounting)
Next - expose all the required steps and start the process.
Full size here
And all - the process ran! Simple and beautiful :) If the route is one of the permanent - you can not fill it every time, but simply save. And if something new is required, we specify it dynamically with changes.
The product Worklite Docs and Worklite Portal for example - you can look here as an example where electronic document management and corporate portal are presented.
Source: https://habr.com/ru/post/194290/
All Articles