My company has 2 Taskspace applications slated for Production deployment in a few months. * These 2 applications just have an overlapping user base. * Both these applications will reside in the same repository, workflow templates for both will be stored in the same repository. * Taskspace App1 will have content attached to the workflow, Taskspace App 2 will not. * Taskspace App 2 has about 500 work queues, Taskspace App 1 about 200. We recently learned that when tasks are brought up in the users' in-box, the overlapping users will see tasks from both workflows. So we are considering our options: * 1.) Create a separate repository just for Taskspace App 2. * 2.) Merge the UI design. * 3.) Keep the UI separate, but add custom logic in the GetNext action that will filter workflows tasks using an undefined formula that will only bring work in depending on the Taskspace application and group you are a member of. * Experienced TS users and experts on this forum - please provide suggestions or links to useful information that will help us decide which course to take. * In case you have not figured out already, this is our first Production deployment with Taskspace. We are also relative newcomers to Documentum - our Production implementation of Documentum went in latter half of 2010. Thanks in advance, Tripti

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Taskspace application - work queues and users question

Trupthy.Bharadwaj

My company has 2 Taskspace applications slated for Production deployment in a few months.

These 2 applications just have an overlapping user base.
Both these applications will reside in the same repository, workflow templates for both will be stored in the same repository.
Taskspace App1 will have content attached to the workflow, Taskspace App 2 will not.
Taskspace App 2 has about 500 work queues, Taskspace App 1 about 200.

We recently learned that when tasks are brought up in the users' in-box, the overlapping users will see tasks from both workflows. So we are considering our options:

1.) Create a separate repository just for Taskspace App 2.
2.) Merge the UI design.
3.) Keep the UI separate, but add custom logic in the GetNext action that will filter workflows tasks using an undefined formula that will only bring work in depending on the Taskspace application and group you are a member of.
Experienced TS users and experts on this forum - please provide suggestions or links to useful information that will help us decide which course to take.
In case you have not figured out already, this is our first Production deployment with Taskspace. We are also relative newcomers to Documentum - our Production implementation of Documentum went in latter half of 2010.

Thanks in advance,

Tripti

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Button

Accepted answers

Miller-zzMST

This is standart function. When you creating a tasklist form template (in fact this form is called 'inbox') on the second step you must to select one or more (with <Ctrl>) processes. Please, have a look at Forms Builder User Guide > Creating Templates > Creating a template for a task list > Selecting processes for a task list template.

Drawback of this method is you must to change this form templete each time as you added a process.

Also, as Johnny said,

you can use a prefix to taskname but with one fix - when you creating a tasklist form you can add a search parameter (and hide from user) with hardcoded prefix

So, you will have two tasklist forms (with corresponding hard-corded prefixes) each for certain Taslkspace application.

~ Konstantin

All comments

DCTM_Guru

Option 1) I wouldnt do this just b/c of work queue requirements. See my blog entry on when creating separate repositories make sense (from my personal perspective):

http://johnnygee.wordpress.com/2006/11/08/too-small-for-our-britches-when-is-it-time-to-create-another-repository/

Option 3) Avoiding customizing Taskspace if all possible. There is no guarantee that customization will work after an upgrade. Taskspace was designed to support wide range of configuration options, but support for customization is minimal.

Option 2) Best bet if you can do this. This approach could be used to support addition of new application for the same user base in the future.

Trupthy.Bharadwaj

Thanks Johnny G!

That is a very useful ink.

One of the ideas that we were discussing was having 2 Inboxes - one for each application for the common users.

Can this be done, in your opinion, by Taskspace configuration and minimal customization or is it extensive customization?

I forgot to mention in my initial post that we are on Documentum 6.6.

DCTM_Guru

I dont think you can configure two inboxes. Inbox is supposed to contain "all" tasks that is assigned to the user. So your "overlap" of workflows in the same UI is expected by design. What is the issue with your users seeing workflows from two apps?

Trupthy.Bharadwaj

I guess there is no real issue as such. It is just that these 2 applications are being developed by 2 different groups. Data, reporting needs, workflow processes etc are completely different.

I agree - an Inbox for each TS application is sort of going against the very concept of an Inbox!

Thanks so much for the information! If we were to go with the 2 Inboxes idea, it would be extensive customization and that may not be acceptable.

Trupthy.Bharadwaj

The reason we wouldn't want one Inbox is also because of this:

If we combine all tasks into one inbox how will the users distinguish or more precisely prioritize work between Taskspace App1 and Taskspace App2? Sure we can add a rank that is determined by the business but they may not even want the work intermingled with each app having different priority logic for determining the type of work to process next.

DCTM_Guru

Here's easy workaround - include prefix in the task activity name:

Ap1: Enter data

Ap2: Review data

This way the user can easily determine which activity corresponds to which application from single Inbox.

Miller-zzMST

Hi!

Also, don't forget what you can make an inbox which will get tasks only from a set of certain processes.

~ Konstantin

Trupthy.Bharadwaj

Thanks, Konstantin!

Could you provide more details on how to do that (is it customization through code or configuration?) - a link will do (if available)

As you can guess, we are new to Documentum Taskspace and so trying to get a feel of what is out there and how others have tackled similar issues

TIA

Miller-zzMST

Drawback of this method is you must to change this form templete each time as you added a process.

Also, as Johnny said,

you can use a prefix to taskname but with one fix - when you creating a tasklist form you can add a search parameter (and hide from user) with hardcoded prefix

So, you will have two tasklist forms (with corresponding hard-corded prefixes) each for certain Taslkspace application.

~ Konstantin

Trupthy.Bharadwaj

Thanks Johnny and Konstantin!

I think we will most likely do the Inbox tasklist filtering based on process. Prefixing task name with a hard coded prefix is good too.

Given that we cannot prevent work from both applications coming into a user's work queue, this will at least make it easier for them to see what kind of work it is.