<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Agreed. <br>
<br>
Thanks for detailing the needs of many of us. I think if RT is to be an
easy to use product for main stream, it needs to address this workflow
issue.<br>
<br>
I don't think that the 6 provided status types will ever fit each
organization, and it needs to be customized for each organization.<br>
<br>
Has anyone scoped out how much work this would require? What I'm asking
for is the ability to add and remove status types that affect workflow.
Or, as Dave just pointed out, put the custom fields on the resolve
screens. Maybe this is more of a U/I issue than a workflow issue.....<br>
<br>
Any other thoughts on it?<br>
<br>
kdl<br>
<pre class="moz-signature" cols="72">K.D. Lucas
<a class="moz-txt-link-abbreviated" href="mailto:lucaskeli@fastmail.fm">lucaskeli@fastmail.fm</a></pre>
<br>
<br>
Dave Dennis wrote:
<blockquote
cite="midPine.LNX.4.58.0406230811220.27144@shell1.speakeasy.net"
type="cite">
<pre wrap="">Actually, not in our case. We've had several workflow discussions in house
about this. What happens is a ticket can be stalled, but for what reason, and
custom fields arent available at resolve time, so that workflow is convoluted.
If we did it by custom statuses and expanded 'stalled' to mean stalled at the
vendors end or stalled inhouse, or even more granular stalled in house because
of shipping, or because of backorder, or what have you ... we'd have a way to
split tickets out that exceeded our SLA, and be able to better explain why to
senior mgt, other than just saying they're 'stalled.' We tried custom fields
for this and that works fine, except for the huge gotcha that the resolve
screens (Listing.html or Update.html) don't show custom fields!!!! So what good
would be a custom field showing a resolve code if you cannot see it without
chunking over to "Basics," updating that, then sauntering back to Update.html
and resolving. Its a workflow headache I can't unleash on a busy staff, sounds
like triviality there I am sure, but turning a 1-click resolve into a 3-4 click
resolve detour is just not acceptable, the custom fields needs to be on the
ticket resolve screens, imho.
Kind regards,
Dave D
+-------------------------
+ Dave Dennis
+ Seattle, WA
+ <a class="moz-txt-link-abbreviated" href="mailto:dmd@speakeasy.org">dmd@speakeasy.org</a>
+ <a class="moz-txt-link-freetext" href="http://www.dmdennis.com">http://www.dmdennis.com</a>
+-------------------------
On Tue, 22 Jun 2004, Michael S. Liebman wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Please don't send HTML only mails to the list.
At 09:58 AM 6/22/2004, Kelly D. Lucas wrote:
</pre>
<blockquote type="cite">
<pre wrap="">My group has been evaluating RT for 2 weeks now, and the only thing we've
found that will cause us implementation headaches is the rigid definitions
of the status field. I suspect that the status field is this way, because
alot of the logic flow of a ticket must be based on the status. Is this
assumption correct?
</pre>
</blockquote>
<pre wrap="">Pretty much. If you take a step back from the process you are working on,
you will probably find the "status" of the process will fit into one of the
broad categories of the ticket status.
</pre>
<blockquote type="cite">
<pre wrap="">After the custom defined fields are added, then have a U/I under
configuration for scrips.
</pre>
</blockquote>
<pre wrap="">You may want to have a look at Arturius's work flow based UI.
</pre>
<blockquote type="cite">
<pre wrap="">Any thoughts? I guess at a minimum, I want a way to add or remove
statuses, and connect the logic flow to them.
</pre>
</blockquote>
<pre wrap="">I would recommend leaving the statuses the way they are and add a custom
field for the specifics you want. For example, if you are trying to use RT
for a provisioning work flow, you would create the ticket with the "new"
status. This might be the first contact with the customer with regard to
the service you are going to provision for them. The status would change to
"open" when sales started working out the details. Your custom field would
be set to "sales." Once things get worked out from there, the custom field
would get set to "field operations" so the could actually go out and do the
work. But the ticket status stays at "open." Once the service is
provisioned, you would set the custom field to "billing" and again leave
the status as "open."
It's not until billing sends out the invoice that you set the status to
"stalled" to indicate you are waiting for a response from the customer.
Your custom field is still set to "billing." That way you know that after x
amount of time, billing needs to follow up to find out where their payment
is. Additionally, you could set the status to "stalled" anywhere else in
your work flow, say when your custom field is "sales," to indicate you are
waiting on the customer. But this time you know it is sales that has to do
the follow up. It shouldn't be too difficult to get scrip with custom
conditions and actions and the cron tool to do what you need to based on
the relation between the ticket status and your custom field.
Hope that helps.
Michael
--
Michael S. Liebman <a class="moz-txt-link-abbreviated" href="mailto:m-liebman@northwestern.edu">m-liebman@northwestern.edu</a>
<a class="moz-txt-link-freetext" href="http://msl521.freeshell.org/">http://msl521.freeshell.org/</a>
"I have vision and the rest of the world wears bifocals."
-Paul Newman in "Butch Cassidy & the Sundance Kid"
_______________________________________________
<a class="moz-txt-link-freetext" href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a>
RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
<a class="moz-txt-link-freetext" href="http://bestpractical.com/services/training.html">http://bestpractical.com/services/training.html</a>
Sign up early, as class space is limited.
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
<a class="moz-txt-link-freetext" href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a>
RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
<a class="moz-txt-link-freetext" href="http://bestpractical.com/services/training.html">http://bestpractical.com/services/training.html</a>
Sign up early, as class space is limited.
</pre>
</blockquote>
</body>
</html>