Community
Showing results for 
Search instead for 
Do you mean 
Reply

[Act, Any version] Act does not handle multi-user environments too well.

Copper Contributor
Posts: 150
Country: Belgium

[Act, Any version] Act does not handle multi-user environments too well.

Imagine the following situation of Act in a single server, no sync, multi-user environment:

 

1) User A on computer A goes to record Y, opens the history tab. History is shown.

2) User B on computer B goes to record Y, opens the history tab. History is shown.

3) User B edits history item nr 1 in record Y. Clicks OK, sees his edit saved.

4) User A edits history item nr 1 in record Y. Clicks OK, sees HIS edit saved, but in doing so overwrites any edit made by user B.

 

Tell me, is it really THAT dificult to program in a quick refresh of the history item right before you show it for editting?

 

Same thing happens with activities:

1) User A is on his own record, on the activity tab. Has a meeting with user B today.

2) User B is on his own record, on the activity tab, has a meeting with user A today.

3) Both users have their meeting, get back to their workstation.

4) User A clears the activity, types his meeting notes in the history generated for the activity.

5) User B clears the activity, overwriting everything user A typed.

 

Could someone please explain to me why this isn't fixed yet?

Nickel Super Contributor
Posts: 345
Country: USA

Re: [Act, Any version] Act does not handle multi-user environments too well.

In my case, It is very unusual that two or more users are working on the same record...

 

Thank you for sharing the results of these tests...

 

This may be fixed in the Act! 2017 version.

 

Best regards.

Juan Carlos Otero
juancarlostero@icloud.com
Administrator
Posts: 4,024
Country: United_Kingdom

Re: [Act, Any version] Act does not handle multi-user environments too well.

Hi EUROPOWERGenerators,

 

Thanks for bringing this to our attention. We've been testing this behavior and have come to the following conclusions:

 

1st scenario:

 

When a history record is opened, it would make sense for Act to re-query SQL for the history record. Currently upon opening a history record, It is likely that Act is reading the history record from the cache that is built when the contact record is first opened (for the preview pane). Ideally, a re-query would happen even in this scenario to avoid data loss.

This has been logged as defect D-05221 to start an internal discussion on the intended behavior and improvements that could be made.

 

2nd scenario:

Please can you provide some more info about this scenario?

  1. What version of Act are you using?
  2. Was the activity scheduled by User A, for User A, and scheduled with User B?
  3. How many total users and contacts have been included in the Activity (including both Scheduled for and with)?
  4. Are the activities, or the resulting histories private?

Here are the outcomes of our testing in Act! v18.2, using the steps you provided:

 

  • If the Activities are cleared non-simultaneously:
    1. User A on their own record, on activity tab, clears activity with User B
    2. Enters notes, and saves
    3. User B was on their own record, has not manually refreshed the record so still see's the activity in the activity tab
    4. User B clears activity
    5. User B sees User A's notes pre-filled in notes field, and can edit or add to the notes
    6. User B saves combined notes
    7. Now there is a single history record with both users in the Contact field
  • If the Activities are cleared simultaneously:
    1. User A on their own record, on activity tab, clears activity with User B, enters notes and saves
    2. At the same time, User B on their own record, on activity tab, clears activity with User A, enters notes and saves
    3. There are now two separate history entries, each created by the clearing user, on the other users record, with the separate notes

If you are experiencing behavior different to this on v18.2, please let us know. Some further troubleshooting would need to take place.

Copper Contributor
Posts: 150
Country: Belgium

Re: [Act, Any version] Act does not handle multi-user environments too well.

After asking around with users scenario 2 was apparantly somewhat different than I first described.

 

- User A & B both have a meeting together.

- They have their meeting, get back to their desk.

- User A clears the activity leaving notes blank. Then heads to the generated history item to add notes and starts typing his notes.

- User B gets to his desk a few minutes later and clears the activity and enters his notes while user A is still editing the generated history item.

- User A gets a few phone calls, takes a lot longer than user B to enter their notes. User B as finished typing his notes in the clear history dialog window and presses OK.

- User A, who was editting in the history window finishes and saves, overwriting user B's notes. (also works the other way around with the user editting in the clear history dialog finishing last).

 

This same problem would probably also exist if 2 users edit the same history item with the 2nd user starting after the first but before the first has finished.

 

Probably the only way to prevent that is some way of record locking so users can't edit the same item at the same time.

Administrator
Posts: 4,024
Country: United_Kingdom

Re: [Act, Any version] Act does not handle multi-user environments too well.

What you've described could be rather tricky to prevent. Record locking is something we have investigated in the past, but ultimately came to the conclusion that this would cause more inconvenience than it would help with these rare clashes. It could be something that we reconsider if the problem becomes a major issue for users.

How often do your users experience issues with this behavior?
Copper Contributor
Posts: 150
Country: Belgium

Re: [Act, Any version] Act does not handle multi-user environments too well.

Well we try to drill into them that they should each make an individual history item with their meeting notes to prevent this from happening, but some of our users are quite forgetful (or refuse to listen) and it happens to them about once a month.
Copper Contributor
Posts: 64
Country: USA

Re: [Act, Any version] Act does not handle multi-user environments too well.

One of my chief complaints with Act at my current company is that it is a great tool for allowing all users to access a centralized contact database, but it is hard to maintain a centralized control over what they do. Sure, you can set a policy and standards, but then you have to pray that people follow them.

 

Even worse is that each users end user experience is largely dependent on the end user. This has pluses an minuses, but the one area where it clearly falls behind for larger organizations is the Smart tasks. If you want to formalize a Business Process in Act via smart tasks, you have to create the smart task for each user, which is not the case in some other systems I work in. My personal view is that without business process automation, all you really have is a fancy rolodex. It's the bridge to cross between Contact Management Software and Customer Relationship Management Software.

Moderator
Posts: 131
Country: United_Kingdom

Re: [Act, Any version] Act does not handle multi-user environments too well.

Hi there, when it comes to Smart Tasks I've always found the most effective way to handle them is to have an administrator set them up on a PC (or server) that is left permanently switched on. In this way there is one user responsible for Smart Tasks so it becomes much easier to identify any problems that have occurred, and you know where to go to fix them.

 

Of course it does depend on the nature of the Smart Tasks you are creating as to whether that will be the most effective setup for you specifically. Can you give me an indication of the kind of tasks that you are setting up?

Copper Contributor
Posts: 64
Country: USA

Re: [Act, Any version] Act does not handle multi-user environments too well.

That is how I do it, but if you have a smart task that needs to be user specific (like if it depends on who the record creator/record manager is), you have to create one for each possible scenario, whereas it should have a variable option that is simply the field. Or you have to know who the record manager will be ahead of time. Let's say you were getting a new contact from a webform, and wanted to let the person it is being assigned to that they had a new contact, and to schedule a follow up call, it would be better to have something like:

 

When ([Record manager] changes values 

    AND [Source] = Company Website )

 

Create new activity (type = call) in one day AND

Send e-mail to [Record Creator:e-mail]