• RE: Presentation download fails

    Me as well. Four tries, four failures.
  • RE: Workflow triggers for new or changed documents

    Simon, I get it but are we sure about this part? 

    "...or actually storing a new document which contains "New Document" as status, would NOT trigger the Workflow."

    Storing a New Document with a Status of "New Document", and having the workflow trigger, is a requirement in my case.

    Are you saying that since new documents have no previous values in any field, any BEFORE conditions would exclude new documents entirely?

    Is that right? It would make the New Documents option irrelevant. That is unless I checked each before condition with EMPTY() or "Removed from Workflow". 

  • RE: Workflow triggers for new or changed documents

    Simon,

    Thank you for that info. I suspected that it would work this way as well.

    I believe the I would only need a "Before" condition if in fact I want to limit the response to only those documents that actually had a certain value prior to the change.

    For example; A BEFORE status of 'Removed from workflow' and an AFTER status of 'New Document' would trigger if I specify that BEFORE status value. Whereas changing the Status to 'New Document' from 'Processed' would not trigger as I have not specified that value as a BEFORE condition.

    Is my assumption correct?

  • Workflow triggers for new or changed documents

    It is easy enough to start a workflow for new documents. Where I need clarification is with a workflow that should trigger for new or changed documents. 
    Since a new document has no previous value in any index field, how should the 'before' section be filled out, or is that simply skipped over for new documents?
    If the conditions for both are the same, it would seem that no documents would trigger, as the requirements for the 'After' section seem to imply that a change must be made.

    Example, I need a document with Status "New" and a document type of "This" OR "That" and a start date of "<="Today" whether it has just now been stored or these fields have been updated (manually or by an AutoIndex process).

    Clues for the clueless appreciated. Or a link to a FAQ if available.
     
  • Error in Workflow when confirming more than one task

    I get an error in Workflow when confirming more than one task in Monitor Tasks window; "2 Documents could not be confirmed". The tasks can be confirmed one at a time. They are all of the same workflow version. 

    Are there any other requisites need to accomplish a multiple confirmation?

    Thanks,
  • Workflow variables type User, Role and Substitution List

    Does anyone know where I can find more specific documentation on using the List type variable for the above named? (V7.1)

    If I create a Role type variable named "Supervisors" and check the List option, what entry type can I use to load that variable? (I'm assuming an Arithmetic Expression like "Supervisor One" AND "Supervisor Two" AND "Supervisor Three").

    And if I use it in a condition what will that variable contain? For example in a Validation, WF_ASSIGNED_TO = GV_SUPERVISORS, does it check each and compare for each element?

    Thanks,
  • Permissions in workflow

    I'm installing a system with many users and complicated document permission requirements. Most users are assigned to File Cabinet Index Profiles to allow or prevent editing of index data and annotations, down to the document and even field level.

    I was working under the assumption (foolishly so, it appears) that since we were required to enter user credentials when creating a workflow, that user would be doing the work. My testing has shown that this is incorrect. In order to update the data of a document, a user with permission to do so is required, as opposed to the global workflow user.

    I have worked around this by making sure any data assignments done during a task, are done to workflow variables and that the task is assigned to a user with Write permission at the file cabinet level, and then using an Assign Data activity to update any Index Data of the Document fields.

    Have I got this right? Is there a document that lays this out, with specificity? Or someone who might set me straight?

    (This brings to mind another question. Any user assigned the new Workflow User license, has read only permissions in the client. How will such a user be able to participate in a workflow that requires Index Data updates)?

    Many thanks,
  • Workflow Monitor Tasks

    The first assignment of a workflow is to a Supervisor's role with the idea that a supervisor will select some tasks and reassign them to individual users.

    When looking at the list of tasks using the 'Monitor tasks' option the same task is shown as assigned to everyone in the role.

    However, selecting a task an reassigning it to an individual user that is not in that role, does not remove the other assignments of that same task to all other users in that role, again using the 'Monitor Tasks.

    Supervisors need to be able to monitor all tasks.  Should not the reassignment remove the original assignment to a Role?

    Clues for the clueless appreciated,
  • AD Synchronization

    We have run an AD synchronization several times. The wokflow is successful and we have refreshed the admin tool but some of the users in the AD groups are not added to the DW groups.

    Any clues appreciated,
  • ...\_ToBeDeleted folders in Web Baskets directory

    I am in the process of moving a v6.12 system to a new server. During the file copy of the Web Baskets directory I see many folders with _ToBeDeleted appended to the name. Opening any of these leads to the familiar 000\000\000 folder structure and eventually to an empty document folder. (There are also many folders in the directory that are not empty). 

    Clearly I could delete these but I'm wondering why they are marked to be deleted but still exist. (System was upgraded from v6.9 way back when). Is there or was there some mechanism in DW that should have deleted these but did not for some reason? Or was this designed to be taken care of by a future upgrade?

    Any clues appreciated,