Tag Archives: itsm

One way of creating approval workflows with OTRS

Approval workflows can be created in different ways on OTRS.

There is a simple way to do that using ITSMIncidentProblemManagement.

With ITSMIncidentProblemManagement package, you get a Decision link on ticket menu. Obviously some configurations have to be done in order to this link be shown only for some users like a department manager (we will call this role decision makers now on). This also can be made in different ways.

I’d like to show a way to create those workflows. I made it this days and see to be efficient.

The concept

We have a group called Service Desk which watchs a queue called “ServiceDesk”. This team receives and process all tickets on the system and try to solve them. They also send some tickets to approval when it’s needed.

So we have to create a queue for each decision group. We may have decision makers on IT and decision makers on HR department for example.

We have those queues on the system:

  • ServiceDesk
  • Ask Approval
    • IT Decision Makers
    • HR Decision Makers
  • Infraestructure specialist
  • Applications specialist

When the ServiceDesk identifies a request which needs approval, they send it to the respective decision maker group.

The Decision Maker approves or not the ticket and he or she move it again to the service desk queue.

How to show Decision link only for decision makers?

Decision Makers will be registered on 2 groups: decisionit and decisionhr

Go to the SysConfig and access Ticket -> Frontend::Agent::Ticket::MenuModule

Find Ticket::Frontend::MenuModule###420-Decision and add a key called “Group” with this content: “rw:decisionit;rw:decisionhr”.

And it’s done!

Making it better

To make the decision maker’s life easier, I created a module (and a package) that moves the ticket to a “next defined queue”, in the same screen where the approval is done. In our example, the ticket will be moved back to the ServiceDesk queue.

You can download this package here.

After it’s installation, you may configure it on Sysconfig -> Ticket -> Frontend::Agent::Ticket::ViewDecisionMove

Other ways

I think OTRS is a very flexible (and not high documented) tool. So, if you know another way to make decisions workflows, please share with us 🙂

OTRS – Funcionalidades

Uma livre tradução e interpretação da página http://otrs.org/feature/

Lista de recursos

Interface Web:

  • Interface Web para que o atendente possa visualizar e trabalhar com os tickets dos clientes
  • Interface Web para administrar o sistema
  • O cliente também pode ver seus tickets e criar novos a partir de uma interface Web
  • Suporte a temas (skins)
  • Sistema unificado de login (ex. HTTPBasicAuth ou LogonTickets)
  • Suporte à vários idiomas (Brazilian Portuguese, Bulgarian, Czech, Chinese, Dutch, Danish, English, Estonian, Finnish, French, German, Greek, Hungarian, Italian, Norwegian, Polish, Portuguese, Russian, Slovak, Spanish, Turkish and Vietnam)
  • Você pode customizar os templates de cada parte do sistema de forma independente (dtl)
  • É possível anexar arquivos nos tickets
  • Uso lógico e fácil

Interface de Email:

  • Suporta MIME (anexos)
  • Suporte PGP
  • Suporte SMIME
  • Encaminhando dos emails entrantes por caixas de correio específicas, ou através de filtragem de palavras do email
  • Respostas automáticas personalizadas para os clientes por fila
  • Converte automaticamente emails html em texto (facilita a pesquisa e economiza espaço no BD)
  • O sistema notifica os agentes por email sempre que há um novo ticket, follow ups ou quando um chamado tá no seu limite de tempo para ser resolvido (SLA)
  • follow up check based on references and in-reply-to header (não sei como traduzir isto, sugestões?)

Ticket:

  • Visão personalizada de filas ou visão de todos os tickets
  • Bloqueio de Tickets
  • Respostas automáticas personalizadas por fila
  • Histórico do Ticket, evolução dos status e ações do ticket
  • Você pode adicionar diferentes tipos de notas aos tickets
  • Ticket Zoom
  • Os tickets podem ser devolvidos ou encaminhados para outros emails
  • Os Tickets podem ser encaminhados para diferentes filas
  • Você pode definir diferentes prioridades para cada tickets
  • Contagem de tempo de cada ticket (e idade do mesmo)
  • Impressão em PDF
  • Pode marcar o ticket como pendente de solução ou de resposta
  • Além do atendente, é possível eleger mais um responsável para o ticket
  • Ações em lote (ex. fechar vários chamados de uma única vez)
  • Ticket hook divider (Alguma sugestão de tradução para esta frase?)
  • Camada de eventos para os tickets
  • Agente Genérico: Automatiza ações em tickets, através de tarefas agendadas
  • Pesquisa FullText
  • Suporte ACL nos Tickets
  • É possível redefinir o Workflow dos Tickets

Sistema:

  • Suporte ASP (activ service providing)
  • Definição de calendários e horários de atendimento para calculos de tempo e SLAs
  • A base de dados de clientes pode vir de um Banco de Dados SQL ou de uma fonte LDAP (ex. eDirectory, AD, OpenLDAP)
  • TicketHook customizável, por exemplo: ‘Call#’, ‘MyTicket#’, ‘Request#’ or ‘Ticket#’
  • Formato de numeração dos tickets customizável
  • Interface XML de banco de dados
  • Camada de banco de dados que dá ao sistema suporte a diferentes softwares, tais como MySQL, PostgeSQL, Oracle, DB2 and MSSQL
  • Um framework de estatisticas e relatórios
  • Frontend e backend com suporte ao charset UTF-8
  • Suporte a instalação de módulos
  • Login de atendentes (agentes) e clientes de diferentes formas: banco de dados, ldap, httpauth ou radius
  • Criação e gestão de contas, grupos e papéis
  • Criação de respostas padrões
  • Criação de sub-filas
  • Criação de assinaturas padrões por fila
  • Criação de saudações padrões por fila
  • Notificação por email disparada pelos administradores
  • Notificação por email enviado para reportar problemas (Não sei se esta é a melhor tradução ou interpretação deste item)
  • Envio de atualizações por email ou pela interface web
  • Deadlines para tickets
  • Fuso horário global
  • Interface Web para configuração do sistema
  • Permalinks para todos os objetos (tickets, faqs, etc)
  • Diferentes níveis de permissão
  • Fácil implementação de addon’s (OTRS API)
  • Facilidade para desenvolver frontends (X11, console, etc)

A fazer:

  • API para interfacear com outros sistemas de gestão de ticket tal como o Peregrine
  • Interface XML