Limiting M-Files Assignments

My idea in my IP actually doesn't work because other workflows and document templates reference person names. If the person name includes some unique identifier for the project PM it will show up in the document templates, what doesn't work.

So, still looking.

Hi AKmarsh,

Interesting demand. Good to see that other also have very demanding customers :).
I am wondering how do you create notifications and assignments in the first place: do you use assignments on workflow states?
Is this person somehow involved in other document types and workflows and argue not get notifications and assignments there?
Can you exclude his account when you prepare notifications in workflow states for specific workflows (I assume you have already tried that and he is potentially in some groups you send the notification)?
I have recently similar feedback from the user: they don't like so much notifications and would like to decide when notification is sent.
I know there is an API (never used it though) to create assignments programmatically. So, if you would take the burden of assignments creation from those state configs perhaps you could control it better. Also not so elegant. I think on notifications you have APIs, I posted recently in forum.

Good luck and let us know.
Dejan

Dejan,

This individual only receives assignments via workflow states (we could use generic assignments, but he has made it very clear he will not respond to those). He is not involved in any other M-Files workflows.

How do you exclude his account when preparing notifications in workflow states when the list of recipients is usually defined based on the properties of the object in the workflow as opposed to manually defined in the workflow?

I do not have any experience using the API. I will do some research.

Thanks for the response.

Hi AKmarsh,

I am not sure if it is possible to halt the creation of assignments entirely.
One way that I thought of would be to maintain an additional property that would programmatically fill out the ones that want assignments.
Kind of like a conditional user list, if you will, that is updated based on an objects properties.

If State == x -> Find users with property y (Could indicate what layer of notifications he/she wants to receive) -> Populate user list -> Assign to people on the list

Thanks for the response, Fred_.

That is an interesting approach. Perhaps one could flip that idea on its head and add some validation to the properties that prevent that user from being assigned to most assignments.

In my typical use case, I can't really pre-define a list of reviewers (say for Meeting minutes) as that is extremely variable.

Thanks for the response!

Hi there, 

Just a curious question - why does this one user of them all refuses to follow way of working of company information tech? :)

One way would just to let things happen if that one user does not want to use the system and ignores the rest, then let the user do so. It just adds to the assignment list of user's view but does not affect systems otherwise. 

It sounds really uncomfortable if document vault must have changes done because of a one user refuses to do the tasks as intended. 

That's a fair question and the answer is fairly simple: M-Files was purchased more-or-less for a single project and has a very small user base (the primary Project plus a couple other smaller projects). Thus, non-Project personnel have no obligation to use the system. Thus, if I want participation from non-users, I have to make it very easy for them, even if that means a bit more work for me as the system admin. 

Finally, if that particular user doesn't respond to M-Files assignments, that will defeat the whole reason I asked him to participate in the first place. 

That is a challenge.

A different inelegant solution would be to use a hidden property and scripting

Create a user property which I will call 'Hidden' and then create a rule that makes sure the property is hidden.

Set an auto calculated or validated script that sets the value equal to the list of assigned users, except it filters out the user in question.

Then create your assignments based on the new hidden property.

Sounds like you have a bad case of change management, among other things. 

Been there. I feel you.

One of the most important aspects of user adoption, including your user that is approaching this with his/her conditions, is the change management. 

But I will say that in the last two years my organization has had this lens of identifying more with the user, it has helped us tremendously and the reputation of the product has significantly been tipped towards more love it than hate/avoid it. 

1) Manager/Leadership buy in. This can't be emphasized enough. Get some leaders on your side. Show them the benefits of Views. Administer smart common Views*, and then teach them how to pin. (*once Common Views are established, don't change them because the Pins will break and that results in users distrusting the product. 

2) Regular training sessions. Everyone learned differently. At my organization, within the first week of a new employee starting, they receive their intro M-Files training. The training is very enthusiastic and takes 1:15. By the end they're convinced they don't need anything else, including their desktop. 

This also means a variety of training resources. We have a common view for all training documents for the org, including a sub-view for M-Files. Here we have one-page tip sheets on different features. The most popular is a one page with quick links to the M-Files tutorial videos they've put on their YouTube channel. Finally, I also have an M-Files Zoom channel to provide tips and tricks - it's received a lot of praise from users working independently in our work-from-home environment.

3) Be open to feedback - Let users vent, they're frustrated with Change fatigue, M-Files is the What vs Where. After listening, show them one thing that might help them, and then be approachable for subsequent conversations. Some of my most resistant users were the ones that had great feedback that made our configuration better. If you can recruit them "to the M-Files side" they'll advocate for M-Files when you're not around. 

We even formed a feedback task force and prioritized improvements based on the discussions. In a few weeks we're also surveying our organization to actually measure people's anonymous opinion of the product, as it will help us to know where to focus our efforts next. 

~~~~

Good Luck, it's a great product and well worth the effort. The key is being aware of not just the technical product, but the users' impression of it. 

~~~~~~

As for your scenario - my suggestion here, is use the "Assigned To" property - when that user is tagged, have a View for them to go to where the filter is documents assigned to them. This can be done using assignments or workflows. 

You can even pin the View with them, so it's super straightforward what they need to do. If they have an assistant - recruit them for support so they see the benefits of this process, and perhaps they will have suggestions to expands its use to more processes. Heh heh heh.