Best posts made by ChristianS9906

It would be helpful if Task Types had a setting allowing them to be specified as being "under development." Under-development tasks would only be visible to Admins in the GUI and reports and invisible to all other users. This would prevent such task types from inadvertently being used by users before they are finalized, potentially resulting in mis-docketed tasks.

Once under-development task types are finalized and tested, the "under development" setting could be removed and the task types made available for general use.

@SadiqA2304 I thought of that but was concerned that it might muck with triggering conditions if the task name was later changed to remove the "under development" text.

It would also mean that normal users would still see it and the under development tasks would still clutter up the interface.

@mike_appcoll Just curious--any ETA on item (c) above?

AppColl allows you to have logins to multiple AppColl accounts, allowing a law firm user to access the law firm's AppColl account and also client AppColl accounts (if given login rights). It's a neat feature.

Right now, to switch accounts you have to go to the account icon in the upper right corner, hover over it, hover over the Switch Accounts menu flyout, and then select the account you want to switch to. You then need to navigate to the matter you want to view in the switched-to account.

In many cases, a user will actually be wanting to switch between accounts to look at the same matter. For example, there may be tasks that need to be completed in two separate accounts for the same matter. It would be a really neat feature if AppColl could, for users having login rights to multiple accounts, identify those matters that exist in two different accounts and then, in the Matter Details view, provide a button that, when clicked, switches between the record for that matter in one AppColl account to the record for that same matter in the other AppColl account. This would let the user flip back and forth between two accounts while still viewing the same matter. This saves the user the hassle of navigating back to that matter in either account after an account switch (and avoids the need to use the Account Switch flyout menu.

I'd like to suggest a new deadline type: "Workflow." Workflow deadlines would be similar to "internal," but would have the ability to be caused to not be displayed in the Matter Details interface if completed (while still displaying other completed deadline types). Tasks with Workflow DeadlineTypes could also be turned on/off wholesale in the Matter Details interface, similar to "Internal" and "USPTO" tasks.

Tasks with Workflow DeadlineType would also be able to be edited by anyone regardless of their permission level.

The idea would be that users could use tasks with this DeadlineType to track various workflow stages, e.g., reported out to client, recommendation sent, response drafted, etc., and then close them out, thereby allowing workflow to be tracked internally. However, external deadlines and events would not be able to be edited except by users with Tasks edit permissions. This allows customers to tightly control access to mission-critical data, e.g., docket and bibliographic data, to their docketing departments while also allowing them to track workflow progress without needing to involve/burden their docketing departments.

Having the ability to screen out completed workflow tasks would allow fairly granular workflows without cluttering the Matter Details task interface with lots of completed workflow tasks....

@support_appcoll Has there been any movement on implementing this idea? It would be hugely useful to have the ability to define some custom fields for tasks.

For example, a field for "In IDS Database" to record whether an Office Action and its cited references have been added to the IDS database. Or "recommendation sent" to indicate that the client has been provided with a recommendation.

Christian

When filtering Matters, it is not possible to select the PatentTermAdjustment as a filter condition. Can this be added?

How does AppColl handle it when it receives an email sent to the intake.appcoll.com domain that does not match any matter? I just deliberately sent a message to an incorrect intake address to see if it would bounce back, and so far, nothing's happening.

We are considering using the new intake address format for emails to clients that use AppColl, but the risk is that sometimes clients change their AttorneyRefs without telling us, resulting in our ClientRef not matching their AttorneyRef until the discrepancy is noticed and corrected. If we then generate and send an email to the client-side email intake address based on our firm-side (ClientRef) version of their AttorneyRef, it will not have a valid intake email address.

If an email sent to the intake address turns out to not be able to be matched to any AppColl matter for the specified customer account, it would be great if AppColl could send an email back to the sender alerting them to the issue--that would a) let them know that the email didn't get saved and b) prompt them to investigate and correct the issue that caused the problem....

Can this be done?

Just checking on whether there's been any movement on this suggestion--it was made nearly a year ago, and the interface is unchanged. This seems like a relatively easy fix to make, and would be a nice quality-of-life enhancement....

Best,
Christian

@BruceY9495 I'm curious as well--it was supposed to have been instituted end of last week.

For the official filing date field, have you been manually updating it with the EBD all these years? I can't recall if it auto-populates, but if it does, it's only doing it for national stage applications.

If you have, good foresight!

@gregg_appcoll Hi Gregg, do you know when the EBD field will be populated with data for all our existing US matters? The field is there, but not very useful to us without that info...would rather not have to add it all manually.

It would be helpful if Matter records had a yes/no field for POA that could be used to indicate if a power of attorney had been accepted for a matter. For example, this can be very helpful when transferring matters in and in identifying cases where a power of attorney has been filed but not yet accepted....

Even better would be if it could automatically determine yes/no status of this field. Not sure if that's possible though.

The browser-based email editor included in AppColl automatically inserts the matter AppCollEmailIntake email address into the recipient list for any email created in it. It does this even if the AppCollEmailIntake email address is not included in the email template that is used to generate the email.

Can this please be fixed? We do not use the EmailIntakeAddress for our own account but do use it for clients that have AppColl and wish us to use their version of it, and it can cause confusion when both are present.

The whole point of having an email template is so that there can be a consistent format for emails, and having the editor decide to override the template and include recipients that aren't supposed to be there seems contrary to that purpose. If a template is intended to reference the EmailIntakeAddress, it is easy enough to include that field in the template--AppColl should not be inserting it on its own.

It would be nice if AppColl could provide a read-only field that was, in effect, a list of previous contacts that had a particular role with respect to a patent application, such as "Attorney" or "Paralegal." Sometimes, it becomes necessary to reassign matters to different individuals, e.g., due to someone leaving the firm or taking an extended leave (e.g., parental leave, sabbatical, etc.).

It would be nice to be able to filter matters based not just on who those matters presently list as attorney, paralegal, etc., but also who they previously listed in such roles. This could help with reversing those assignments at a later date if the previously assigned person returns to work at the firm.

For example, an "AttorneyHistory" field could store all attorneys that have been assigned to a matter, while ParalegalHistory could do the same for all paralegals that have been assigned to the matter. You could have ContributorHistory, PartnerHistory, and ClientContactHistory as well, but those likely aren't quite as immediately useful.

Otherwise, one has to either think ahead and export the previous assignments before updating them (so you can do a bulk reverse update if you want to restore the original assigned practitioner/paralegal) or parse through the Transaction History to identify all cases where the original assigned practitioner/paralegal was changed, and then craft a filter that identifies all of those matters by docket number (which could easily require multiple queries due to the filter string length limitations).

The Contact merge interface does not show first/middle/last names as separate columns. When you have multiple contacts that only differ in that one of their names is actually a double name, e.g., John David as first name instead of John as first name and David as middle name, the two contacts appear identical in the Merge interface, so you don't know which one you are picking as the primary contact....

Can this be fixed?

Trigger condition editing for Tasks in AppColl is in dramatic need of improvement--there is no ability to insert new triggers in between existing triggers, or to change which "when" clause a given "while" condition is "anded" with.

This makes defining new tasks or modifying existing ones extremely tedious. For example, if you have a task with multiple different trigger scenarios, each with its own WHEN clause that each have their own WHILE clauses, you might easily have 10-12 separate trigger conditions, e.g., 3 WHEN clauses, each with its own set of 3 WHILE clauses. If you realize that you need to tweak the triggering by adding another WHILE clause to the last WHEN clause, no big deal--just tack it on and you're done. But if you need to do it to the first-listed WHEN clause, you're out of luck--you have to delete the second and third WHEN clauses and all their WHILE clauses, add the new WHILE clause to the first WHEN clause, and then re-construct the second and third WHEN clauses and all their WHILE clauses. In the example above, you'd have to delete 8 of your 12 trigger clauses, add the additional trigger clause, and then re-build the deleted clauses.

Suggestion: The trigger conditions for a TaskType are currently listed in a table format, with the WHILE conditions indented in rows below their parent WHEN condition. Just add a button to each WHEN condition row in the table that would, when the user clicks it, allow the user to insert a new WHILE condition for that WHEN condition. The newly added WHILE clause would be added after the existing WHILE clauses for the relevant WHEN clause. This would entirely solve the significant usability issue noted above.

Icing on the Cake Suggestions: Maybe also add up/down buttons to allow the order of trigger conditions to be changed. This would be more of a cosmetic change, as changing the order of WHILE clauses within a WHEN clause would have no functional impact--but it would allow users to re-organize the WHILE conditions within a WHEN condition so that they are more consistent between WHEN conditions for a given TaskType. And it would allow a WHILE condition to be moved up or down into an adjacent WHEN condition, which would affect function but also potentially be useful if you put a WHILE condition in the wrong WHEN condition and want to relocate it.

Finally, the UI already has the ability to individually delete any condition--except the first WHEN condition. It really should allow the user to delete that one as well. There are times when you define a set of task triggers to have multiple WHEN conditions, and then later you realize that the first one isn't needed any more. But you can't delete it without deleting all trigger events and then rebuilding the ones you want to keep. Or by changing the first WHEN condition to be the last WHEN condition and updating its WHILE conditions to match (only works if first WHEN has same or greater number of WHILE conditions as last WHEN condition or if you only have two WHEN conditions).

Screenshot below showing suggested revisions to TastType definition UI.