I have an assignment rule on case object
If the criteria meets the case owner name will be a queue( which has 10 users)
Now how can i know among the ten users who have picked up the case and how does the other users can know that the case has been picked up by x user
Train users that if they pick some work from the queue - they need to first claim it (change owner to themselves). There's big "Change Owner" button on case listviews as well on single case page layout. Unless your admin decided to hide it.
If they're notoriously bad at it and you have more than 1 person working on Case - you could think about some enforcing the rule. A validation that you can't change case's status from New unless the owner isn't human for example. Or that you can't close the case unless you own the case. It'd annoy them a bit (fill all the fields needed for closing, hit save, boom, error, need to cancel, change owner, edit again) but after a while they'll get the hint.
But that's the "nasty admin" way, making the system hostile. Start with training, with the value of "My Cases", "My Open Cases" listviews, not just queue queue.
You could also try to always set the owner to whoever edited the case last but that might be tricky if you have some nightly jobs that update them or "inbound email handler" that finds & reopens case for example... Start with training.
Related
I want to show a different option to the user in workflow through input node, depending upon whether the user has modified the record or not.
Problem is if I would use a condition node with custom class to detect whether object has been modified by some person or not in between the workflow process then as soon as the person clicks on route workflow the save is automatically called and isModified() flag gets false, How do I get in condition node whether some person has modified the record or not.
I have to show different options to the user if he has modified and different option on routing workflow if he have not modified.
Sounds to me like you need to enable eAudit on the object and then to check whether eauditusername on the most recent audit record for that object bears the userid of the current user.
It's a little hokey and tempts fate, but if your condition node is early in the workflow's route when this button is pressed, you could try and check to see if the changedate on the object (assuming you are working with one of the many objects that has one) is within the last 5 seconds. There is a gap where the record could be routed twice within a few seconds, but the gap is fairly hard to hit. There is also a gap where if the system slows down at that point and takes more than 5 seconds to get to and run your condition, then it would appear to be not modified. You can play with the delay to find a sweet spot of the fewest false positives and negatives.
I have two conversation nodes defined. The first is triggered on conversation_start and asks the users's name. The second stores the user name from input.text in a context variable and asks if the user wants to take a brief survey or do something else. The second one never executes. What should the trigger be on the second one in order to advance the conversation? There is no intent or condition set yet. Basically, I just want to follow a string-of-pearls pattern where every question gets asked and let the user opt out of some of the questions.
there are two main ways to achieve this. The one I recommend is to create an intent for each possible way. For example, you could create an intent called #affirmative, with values like "Yes", "Yeah", "Sure", "Ok", etc. All you have to do is to create the intent and then use it in the condition field.
But you can also check the user's input directly, using input.text. For example, you could use input.text.toLowerCase() == 'yes' as the condition. Have in mind that this should only be used if you are controlling the input and only allowing a few possible values. If not, use an intent and let Watson Conversation handle the input parsing for you.
Another really cool feature that Watson Conversation provides that can benefit is you is to have a node with a condition like intents[0].confidence < 0.6 and a response like "Sorry, I didn't get that". That way you make sure your flow will only trigger a condition with a high confidence for the intent.
Hope it helps!
You can use the jump to function to route the system to arbitrary dialog_node - this is great for creating directed dialogs. So whenever you want to continue with the next question (user answered the previous question), you can use jump to from the node processing the answer to the previous question to ask the user another question (jump to the body part of the next dialog node asking new question).
Now for "get name" use case you want the second node gathering the name from the user input hanging off the conversation_start node. If the conversation encounters a node that has children, the processing of the next dialog round will start at the first child of this dialog node - this way the contextual dialogs are defined in the conversation.
Bluemix Conversation can be thought of as a state machine. Each transition is diagrammed in the tooling, but each node can only be triggered by a condition. So that if you're on a node asking a question, and the answer that comes back does not trigger one of the child nodes, the state will not transition to a child. Answers entered into a node are processed by Watson, who provides "intents", which are essentially keywords found in the sentence he just analyzed. So one way to advance the conversation is to match named "intents" using the # prefix to the trigger of in a child node. Another way it to match named "entities" using the # prefex, although it is less clear how Watson builds entities. The third way is to match context variables using the $ prefix and simple conditional operators such as ==. Context variables are entirely managed by you, the developer. You are allowed to set one context variable at each node. And then you can use it to trigger a child node. This appears to be a good approach to managing the type of conversation I want to implement. The fourth way is to use the previous parent node's input value using along with simple conditional operators.
In OS/X I have a Customer table with the fields Name, TaxCode, and Address defined with the "required" attribute (other fields not). In a layout without any of these required fields I execute a script with a Perform Find[Restore] step which looks for records containing value 1 in another field of the same table.
I have traced the script execution and when the script reaches the Perform Find step the following Dialog pops:
"Name" is defined to require a value. Allow this field to remain empty?
Revert Record No Yes
If I click Yes then comes an identical message for each of the remaining "required" fields in the table. Eventually the script finishes as expected, but of course this manual intervention makes the query cumbersome and unacceptable.
What is happening? and what can I do?
In your layout, there is a record with open state that doesn't meet your requirements. When you try to enter find mode, it fails to commit.
Try to use Get ( RecordOpenState ) to see what you get in the layout before you enter find mode – 0 is committed, while 1 and 2 are records not committed.
Also, make sure you do not have a "new record/request" script step before the "enter find mode"; it could be the reason of your trouble.
I checked the contents of the Customer table and found a register with all the fields empty. Once this record was deleted, the problem disappeared.
Cannot remember/explain how the empty record came about, probably some trouble during the creation process. What still surprises me is the circumstances in which Filemaker verifies the correctness of fields NOT involved in the actual Find.
Thanks for the suggestion.
We've got a set of forms in our web application that is managed by multiple staff members. The forms are common for all staff members. Right now, we've implemented a locking mechanism. But the issue is that there's no reliable way of knowing when a user has logged out of the system, so the form needs to be unlocked. I was wondering if there was a better way to manage concurrent users editing the same data.
You can use optimistic concurrency which is how the .Net data libraries are designed. Effectively you assume that usually no one will edit a row concurrently. When it occurs, you can either throw away the changes made, or try and create some nicer retry logic when you have two users edit the same row.
If you keep a copy of what was in the row when you started editing it and then write your update as:
Update Table set column = changedvalue
where column1 = column1prev
AND column2 = column2prev...
If this updates zero rows, then you know that the row changed during the edit and you can then deal with it, or simply throw an error and tell the user to try again.
You could also create some retry logic? Re-read the row from the database and check whether the change made by your user and the change made in the database are able to be safely combined, then do so automatically. Or you could present a choice to the user as to whether they still wish to make their change based on the values now in the database.
Do something similar to what is done in many version control systems. Allow anyone to edit the data. When the user submits the form, the database is checked for changes. If the record has not been changed prior to this submission, allow it as usual. If both changes are the same, ignore the incoming (now redundant) change.
If the second change is different from the first, the record is now in conflict. The user is presented with a new form, which indicates which fields were changed by the conflicting update. It is then the user's responsibility to resolve the conflict (by updating both sets of changes), or to allow the existing update to stand.
As Spence suggested, what you need is optimistic concurrency. A standard website that does no accounting for whether the data has changed uses what I call "last write wins". Simply put, whichever connection saves to the database last, that version of the data is the one that sticks. In optimistic concurrency, you use a "first write wins" logic such that if two connections try to save the same row at the same time, the first one that commits wins and the second is rejected.
There are two pieces to this mechanism:
The rules by which you fail the second commit
How the system or the user handles the rejected commit.
Determining whether to reject the commit
Two approaches:
Comparison column that changes each time a commit happens
Compare the data with its committed version in the database.
The first one entails using something like SQL Server's rowversion data type which is guaranteed to change each time the row changes. The upside is that it makes it simple to roll your own logic to determine if something has changed. When you get the data, you pull the rowversion column's value and when you commit, you compare that value with what is currently in the database. If they are different, the data has changed since you last retrieved it and you should reject the commit otherwise proceed to save the data.
The second one entails comparing the columns you pulled with their existing committed values in the database. As Spence suggested, if you attempt the update and no rows were updated, then clearly one of the criteria failed. This logic can get tricky when some of the values are null. Many object relational mappers and even .NET's DataTable and DataAdapter technology can help you handle this.
Handling the rejected commit
If you do not leave it up to the user, then the form would throw some message stating that the data has changed since they last edited and you would simply re-retrieve the data overwriting their changes. As you can imagine, users aren't particularly fond of this solution especially in a high volume system where it might happen frequently.
A more sophisticated (and also more complicated) approach is to show the user what has changed allow them to choose which items to try to re-commit, Behind the scenes you would retrieve the data again, overwrite the values picked by the user with their entries and try to commit again. In high volume system, this will still be problematic because by the time the user has tried to re-commit, the data may have changed yet again.
The checkout concept is effectively pessimistic concurrency where users "lock" rows. As you have discovered, it is difficult to implement in a stateless environment. Users are notorious for simply closing their browser while they have something checked out or using the Back button to return a set that was checked out and try to recommit it. IMO, it is more trouble than it is worth to try go this route in a web-based solution. Assuming you write the user name that last changed a given row, with optimistic concurrency, you can inform the user whose changes are rejected who saved the data before them.
I have seen this done two ways. The first is to have a "checked out" column in your database table associated with that data. Your service would have to look for this flag to see if it is being edited. You can have this expire after a time threshold is met (with a trigger) if the user doesn't commit changes. The second way is having a dedicated "checked out" table that stores id's and object names (probably the table name). It would work the same way and you would have less lookup time, theoretically. I see concurrency issues using the second method, however.
Why do you need to look for session timeout? Just synchronize access to your data (forms or whatever) and that's it.
UPDATE: If you mean you have "long transactions" where form is locked as soon as user opens editor (or whatever) and remains locked until user commits changes, then:
either use optimistic locking, implement it by versioning of forms data table
optimistic locking can cause loss of work, if user have been away for a long time, then tried to commit his changes and discovered that someone else already updated a form. In this case you may want to implement explicit "locking" of form, where user "locks" form as soon as he starts work on it. Other user will notice that form is "locked" and either communicate with lock owner to resolve issue, or he can "relock" form for himself, loosing all updates of first user in process.
We put in a very simple optimistic locking scheme that works like this:
every table has a last_update_date
field in it
when the form is created
the last_update_date for the record
is stored in a hidden input field
when the form is POSTED the server
checks the last_update_date in the
database against the date in the
hidden input field.
If they match,
then no one else has changed the
record since the form was created so
the system updates the data.
If they don't match, then someone else has
changed the record since the form was
created. The system sends the user back to the form edit page and tells the user that someone else edited the record and they must reapply their changes.
It is very simple and works well enough.
You can use "timestamp" column on your table. Refer: What is the mysterious 'timestamp' datatype in Sybase?
I understand that you want to avoid overwriting existing data with consecutively updates.
If so, when the user opens a screen you have to get last "timestamp" column to the client.
After changing data just before update, you should check the "timestamp" columns(yours and db) to make sure if anyone has changed tha data while he is editing.
If its changed you will alert an error and he has to startover. If it is not, update the data. Timestamp columns updated automatically.
The simplest method is to format your update statement to include the datetime when the record was last updated. For example:
UPDATE my_table SET my_column = new_val WHERE last_updated = <datetime when record was pulled from the db>
This way the update only succeeds if no one else has changed the record since the last read.
You can message to the user on conflict by checking if the update suceeded via a SELECT after the UPDATE.
I keep seeing questions floating through that make reference to a column in a database table named something like DateLastUpdated. I don't get it.
The only companion field I've ever seen is LastUpdateUserId or such. There's never an indicator about why the update took place; or even what the update was.
On top of that, this field is sometimes written from within a trigger, where even less context is available.
It certainly doesn't even come close to being an audit trail; so that can't be the justification. And if there is and audit trail somewhere in a log or whatever, this field would be redundant.
What am I missing? Why is this pattern so popular?
Such a field can be used to detect whether there are conflicting edits made by different processes. When you retrieve a record from the database, you get the previous DateLastUpdated field. After making changes to other fields, you submit the record back to the database layer. The database layer checks that the DateLastUpdated you submit matches the one still in the database. If it matches, then the update is performed (and DateLastUpdated is updated to the current time). However, if it does not match, then some other process has changed the record in the meantime and the current update can be aborted.
It depends on the exact circumstance, but a timestamp like that can be very useful for autogenerated data - you can figure out if something needs to be recalculated if a depedency has changed later on (this is how build systems calculate which files need to be recompiled).
Also, many websites will have data marking "Last changed" on a page, particularly news sites that may edit content. The exact reason isn't necessary (and there likely exist backups in case an audit trail is really necessary), but this data needs to be visible to the end user.
These sorts of things are typically used for business applications where user action is required to initiate the update. Typically, there will be some kind of business app (eg a CRM desktop application) and for most updates there tends to be only one way of making the update.
If you're looking at address data, that was done through the "Maintain Address" screen, etc.
Such database auditing is there to augment business-level auditing, not to replace it. Call centres will sometimes (or always in the case of financial services providers in Australia, as one example) record phone calls. That's part of the audit trail too but doesn't tend to be part of the IT solution as far as the desktop application (and related infrastructure) goes, although that is by no means a hard and fast rule.
Call centre staff will also typically have some sort of "Notes" or "Log" functionality where they can type freeform text as to why the customer called and what action was taken so the next operator can pick up where they left off when the customer rings back.
Triggers will often be used to record exactly what was changed (eg writing the old record to an audit table). The purpose of all this is that with all the information (the notes, recorded call, database audit trail and logs) the previous state of the data can be reconstructed as can the resulting action. This may be to find/resolve bugs in the system or simply as a conflict resolution process with the customer.
It is certainly popular - rails for example has a shorthand for it, as well as a creation timestamp (:timestamps).
At the application level it's very useful, as the same pattern is very common in views - look at the questions here for example (answered 56 secs ago, etc).
It can also be used retrospectively in reporting to generate stats (e.g. what is the growth curve of the number of records in the DB).
there are a couple of scenarios
Let's say you have an address table for your customers
you have your CRM app, the customer calls that his address has changed a month ago, with the LastUpdate column you can see that this row for this customer hasn't been touched in 4 months
usually you use triggers to populate a history table so that you can see all the other history, if you see that the creationdate and updated date are the same there is no point hitting the history table since you won't find anything
you calculate indexes (stock market), you can easily see that it was recalculated just by looking at this column
there are 2 DB servers, by comparing the date column you can find out if all the changes have been replicated or not etc etc ect
This is also very useful if you have to send feeds out to clients that are delta feeds, that is only the records that have been changed or inserted since the data of the last feed are sent.