• State Not Answered
  • Replies 7 replies
  • Subscribers 11 subscribers
  • Views 5951 views
  • Users 0 members are here
Related Discussions
Home » Discussions » Best Practices

Transitioning from Portal to Tempo

John Stretton

I'm in a very small group (3 people) responsible for building and maintaining BPM applications for my company. A few months ago, we started to build all of our new applications in Tempo, and now we want to get our users accustomed to using Tempo. However, we still have several applications that only work in the Portal environment. These applications are large and complex enough that it's not feasible to redesign them as Tempo applications all at once, so for a significant amount of time people will need to be able to use both the Tempo and Portal environments.

Does anyone have experience making this kind of transition from Portal to Tempo? Do you have any advice for how we might handle this?

OriginalPostID-167998

OriginalPostID-167998

  Discussion posts and replies are publicly visible

Parents
  • 0
    Like most things I think that it depends. Are your users switching back and forth between portal\          empo? I would try to keep each user group on one side or the other.

    I had an application back in the early days of tempo when there were only a handful of fields that were "tempo enabled". It was the type of app that had a bunch of front office workers send\\receiving requests and only a few back office workers processing them. Because portal was better (at the time) for managing lots of requests from a single view, it worked great for our back office. Meanwhile the front office liked having tempo's easy to use interface for entering\\managing their requests. My point here being that neither side new or cared about the other. They only know and care about what they are working on.

    So as long as you provide a consistent experience, you're on the right path. If that's not possible, then I would treat portal and tempo as different sites. Your average user won't care about the differences. The worst thing I think is to have tempo and portal mixed on the same application for the same user. Getting a portal popup while working on tempo is bad.
Reply
  • 0
    Like most things I think that it depends. Are your users switching back and forth between portal\          empo? I would try to keep each user group on one side or the other.

    I had an application back in the early days of tempo when there were only a handful of fields that were "tempo enabled". It was the type of app that had a bunch of front office workers send\\receiving requests and only a few back office workers processing them. Because portal was better (at the time) for managing lots of requests from a single view, it worked great for our back office. Meanwhile the front office liked having tempo's easy to use interface for entering\\managing their requests. My point here being that neither side new or cared about the other. They only know and care about what they are working on.

    So as long as you provide a consistent experience, you're on the right path. If that's not possible, then I would treat portal and tempo as different sites. Your average user won't care about the differences. The worst thing I think is to have tempo and portal mixed on the same application for the same user. Getting a portal popup while working on tempo is bad.
Children
No Data
© 2024 Appian. All rights reserved.
We want to hear from you! Submit a review on Gartner or G2.