Best posts made by ChristianS9906

AppColl includes a "Transient Event" DeadlineType that was created responsive to input I provided several years ago. A transient event is just like a normal event except that it comes into existence and then immediately deletes itself--however, it triggers any follow-on tasks that might be needed and sends out notifications associated with it prior to disappearing.

It would be very nice if the Tasks framework were to be updated so that any TaskType could be made to be "transient," i.e., made to self-delete once no longer "Open." For example, every TaskType definition could have a "Transient" (or "Delete Once Closed" if a more descriptive name is desired) setting, e.g., a checkbox, that can be checked for a TaskType if that TaskType is to self-destruct once closed out.

This would be a little different than how the existing Transient Event DeadlineType works in that non-Event TaskTypes with this setting enabled would not immediately self-delete, but would stay visible on the docket until closed out. However, the existing Transient Event DeadlineType should be implementable under this new framework as well, e.g., as a normal Event DeadlineType that has the "Transient" setting enabled--since Events are tasks that instantly complete themselves, the "transient"-enabled Event should work like the current Transient Event DeadlineType.

The benefit to having this setting is that it would allow for intermediate deadlines, e.g., reminder deadlines, to be auto-closed and then disappear from the docket, as opposed to cluttering it up in a "completed" state. We like to have our docket be relatively streamlined, e.g., free of low-value entries. An advance reminder of an upcoming foreign deadline, for example, is useful to have on the docket, but once that reminder is in the past, it really isn't something we need to keep seeing.... Being able to have it automatically clean itself off the docket would be a nice capability to have (and would save our docketing department time and effort).

AppColl offers the ability for users who have Report creation permissions to make a report "Private", which is great. It would be really nice, however, if the Permissions manager in AppColl could have a setting that could give add/delete/modify Report privileges to a user but only for private reports. In other words, that user could add/delete/modify reports that they make, but not modify/delete reports that others have made. Moreover, any report made by such a user would automatically be a "private" report so that others cannot see it. Ideally, those permissions would extend through to the Manage Report Schedules as well, e.g., those users could manage schedules for their private reports, but NOT add/delete/modify schedules for other reports.

For example, we want our practitioners and secretaries to be able to make their own reports and schedule them to be sent to themselves (if desired), but we do not want them to be able to modify other reports, e.g., ones that sys admins have set up for general use by anyone in the firm. Right now, there isn't a happy middle ground that will let us do that. We have to give full report permissions to our users and just trust that they will not accidentally modify a report that they have no ownership of.

It would also be great if the "Reports" combo box in each module could have a toggle that lets the user flip between listing all reports, only private reports, and (possibly) public reports.

Cheers,
Christian

@MikeO5888 I second Bernd's suggestion--I've actually suggested this to Support in the past, prior to the forum's existence. This would be a trivial addition to the GUI--the hyperlink needs data that is already retrieved from the database, so little effort needed to implement.

Google patents is not as useful as Patent Center--it lags Patent Center and it also doesn't include all the other information, such as the IFW, that Patent Center has. It also does not include non-published cases.

If this is implemented, would recommend also having a direct link to the IFW for each matter. Same hyperlink, but with some sub-folders specified:

https://patentcenter.uspto.gov/applications/<APPNO>/ifw/docs

Christian

It would be great if users could have the ability to specify alternate column headings to be displayed in reports, i.e., aliases that, if present, would be displayed as the column header for a given field.

For example, clients often request that we send them reports of their docket data, but with column headers labeled in a certain way (for example, they want to see "XYZ Docket Number" instead of "ClientRef" or "OC Reference Number" instead of "AttorneyRef" or "Responsible Manager" instead of "ClientContact").

Ideally, we'd just create a report for this information and then set up an autoschedule to send it to the client on a specified timeframe...except that we can't because we need to first send it to someone in our firm who manually replaces the column headers with the desired column headers.

If this was implemented, I think it would be fine if those aliases are only shown in "Print" view, when the report is inserted into an email/form letter, and when the report is exported to PDF or CSV/Excel format. I don't see a strong need to see the aliases in the interactive GUI itself (although it might be nice).

Can this be implemented? It would really make reports much more useful for communicating information to clients.

Best,
Christian

It would be helpful to have the inventor status listed or indicated in some way on the Matter Details interface. For example, when sending a draft application to inventors, it would be helpful to be able to see which inventors are active/inactive so that we can easily decide which inventors to include on distribution.

Right now, you can only see the inventor status information if you click on each individual inventor to inspect their additional details.

There is the ability to export an AppColl Inventors (CSV) file for matters. The output file includes Matter, Inventor, AsFiled, and Rank as the fields.

I would like to request that it also include ContactID for the inventors listed. "Inventor" is not a unique record identifier, as different inventors can have the same names.

We don't currently use the Billing module, but I am listening to the webinar on it right now. The ability to specify, on a client-by-client basis, what UTBMS billing codes are available for use, and to specify custom descriptions (with field code capability) that are used by default each time such a UTBMS code is selected, would be very useful.

We have multiple, large clients that use UTBMS codes in different ways (e.g., some use 430 for all office actions, while others use it only for non-final OAs and then use 435 for final OAs). We also have clients that expect specific language in the billing entry description for particular task codes, e.g., "{Matter.CountryCode} Request Examination Recommendation." They do not want us to deviate from this language. Our current billing system auto-fills it for us based on the UTBMS code selected.

It would also be ideal to have multiple entries for a given UTBMS code for a client--for example, the client might have different budgeting frameworks for the same UTBMS task code depending on complexity of the task. Ideally, each of these task codes could have an alias that the customer can specify to allow them to easily differentiate between each of several options for a given UTBMS code for a client.

If AppColl is set up to process e-Office Actions, it will automatically create a "USPTO e-Office Action: XXXX" Event task type for each different e-Office Action document code XXXX that it processes. It will also create a corresponding Hard External Deadline "Review USPTO e-Office Action XXXX" task type for that newly created Event task type.

It would be nice if there was a way to let the account admin have more control over how this system works. In particular, it would be nice if a) the admin could make it so that newly generated "USPTO e-Office Action: XXXX" Event tasks are instead created as Transient Events by default and b) the admin could instruct AppColl to not make "Review USPTO e-Office Action XXXX" task types at all.

At present, 25% of our 760 different task types are e-Office Action-related task types (split evenly between the Event task types and the Review USPTO e-Office Action task types). We never use the Review USPTO e-Office Action tasks, and immediately disable auto-generation as soon as we detect a new version of such a task. It would be great if we could simply tell AppColl not to bother making such task types going forward.

For the USPTO e-Office Action Event tasks, we want them to trigger since they may be needed to trigger follow-on tasks, but we don't want them hanging around since they are just extra clutter--the event date, if important, is always reflected in the RefDate of a task triggered by such an event, so there is zero benefit to keeping the USPTO e-Office Action Event tasks around. In view of that, we always change them to Transient Event types. But when a new one gets created by AppColl, we have to go track it down and change it. It would be nice if we could have AppColl default to defining these as Transient Events instead of as Events.

It would be nice to have an "archive" feature in AppColl--essentially, an archive AppColl account for each customer that stores record data separately from the customer's main account so that searches/reports done while in a customer's main account don't show the records in the archive account (and vice versa). Records could be moved back and forth between the two accounts by account holders.

This would, for example, allow records for disengaged clients or transferred-out files to be removed from the record pool of the main account, which would keep them from needing to be processed when generating reports. For example, right now nearly 20% of our matters and tasks have a transferred out status (a total of 70,000+ records); we would only need to look at them if their new stewards had a historical question about such an application. We could just delete these records, but prefer to keep them on-hand just in case.

Records in the archive account would not have auto-triggering--it would just be a static repository of records for archival purposes.

Seems like a potentially useful feature....

I wasn't able to attend the webcast on the new module--my apologies if these features were addressed in the discussion (I did review the help files and didn't see mention of them, however).

Two features that would be good to have for this:

a) The ability to "force" use of non-stylized signatures when using DocuSign, i.e., do not allow "typed" signatures and require that a signature either be input directly using stylus or from a scan. Some jurisdictions allow for DocuSign-like signatures but require that the actual signature that is used for DocuSign be input by hand.

b) The ability to see what the current signature for a signatory will look like prior to sending out documents for signature. This would help identify signatures that may be undesirable so that the signatory can be contacted and asked to make corrections prior to sending out the document for signature. This would allow a document preparer to avoid scenarios like:

i) scanned signature is from a scan with a dark background (resulting in a dark rectangular block with a darker signature in it).

ii) scanned signature is upside down or rotated 90 degrees.

iii) scanned signature is too low quality (poor resolution or too faint).

iv) scanned signature is microscopic/very small when reproduced, making it illegible.

The above feature would be best combined with a system that lets potential signatories that aren't signed up with DocuSign be enrolled into DocuSign before they need to sign documents so that their signatures can be vetted ahead of time.

Just my two cents....

The new "secondary" email intake address opens some interesting possibilities for those of us who have clients who also use AppColl. For example, we can now relatively easily create a client-side intake email address based on information that we already store in our law firm-side AppColl dataset.

In our case, we have a custom field in our law firm-side AppColl that we use to store our clients' client-side intake email address. We have to manually add that address (or do occasional bulk imports) for those of our clients that are not willing to use the sync feature in order to populate this data. With the secondary email intake address, we could, in theory, construct the secondary email intake address on-the-fly, e.g.: "acctname{ClientRef}@intake.appcoll.com," based on data we already have (ClientRef).

There are two potential issues with this:

a) I don't know what happens if the client AttorneyRef (our ClientRef) is later changed--does the secondary email intake address change to match? I assume it must since you might otherwise have email go to the wrong matter (if a different matter is later opened with the retired AttorneyRef), but it would be nice to have confirmation of this.

b) Ideally, there'd be a field in the Client contact record that could be used to store the "acctname" data so that the address could be constructed completely dynamically. We could use an existing Contact field for that, but it would be nice if there was a dedicated field for this purpose.

Interesting possibilities.....

@joe_appcoll Great, thanks!

Right now, if you Sync Connections from one account to the other, the existing Connections are overwritten in the recipient account. Clients are usually the ones requesting and receiving syncs from their OC; this causes issues since clients are usually also using Invention Manager, which creates IDF records that are then "connected" to the eventual application(s) that they spawn. OC, however, don't usually have Invention Manager and don't have records of their clients' IDFs. As a result, OC's connection data doesn't have the IDF linkages.

This presents a problem when OC syncs connection data to a client, as the current sync causes a wholesale replacement of the client's connection data (for all connections) to be overwritten with the OC connection data. Thus, connections that the client has between IDFs and applications will get overwritten and lost.

It would be a nice if AppColl could be set up so that users that receive syncs could specify what level of syncing should be performed on connections, e.g.:

• Sync priority connections (y/n)?
• Sync subject matter connections (y/n)?
• Sync IDF connections (y/n)?

AppColl would then only sync connections that match the connection types selected. For example, if an account owner specified "y" for priority connections only, then AppColl would, when syncing, only remove and replace connections that are "priority" connections. It would leave any "subject matter" or IDF connections alone.

Since we are not Invention Manager users, I don't know if IDFs have a separate connection type--if they are also "subject matter" connections, it might be nice to allow users to treat them differently from other non-IDF subject matter connections, so I broke them out as a separate category above.

Is this something that could be implemented?

Without it, it makes the Sync feature for connections data pretty much unusable.

Best,
Christian

@jonah-soundhound-com Yeah, I thought of that as well--but at some point, too much customizability becomes problematic for AppColl since it makes it difficult for them to write coherent instructions for users (if you have a screen shot showing where fields are but users may have completely different UI layouts, that may introduce headaches).

However, one way to maybe address that is to have a button/toggle in the UI that lets users instantly flip between a "default" AppColl UI layout (like it is now) and a customer-defined layout (in which admins could reposition any fields to suit the needs of their attorneys/admins). That way AppColl's help files are still applicable to the AppColl default, but users can also use custom layouts--with the understanding that AppColl help files are intended to be directed at the default layout....

@MikeO5888 Actually, there is a workaround....

The 2K limit is, it is true, a browser-inherent limit. But not all browsers are created equal....

Chrome and Edge, for example, seem to have limits of around 2K for MailTo link text.

However, Firefox seems to have a massive larger limit. For example, I have been able to successfully generate emails from AppColl in Outlook using Firefox that have nearly 24,000 characters (5+ pages of solid text in Word).

Keep in mind that if Firefox ever reduces that limit, there is nothing AppColl can do about it. At the same time, Chrome and Edge might raise it, allowing them to be used in a similar manner....

So if you're willing to use Firefox as your AppColl browser, you should be able to have much more flexibility in terms of the size of the email template for direct creation in your Outlook client.

Cheers,
Christian

@jonah-soundhound-com Would it work to just have a "matters" button in the Contact details interface that will list all matters where that contact is listed in any capacity? Or is there a reason to have different buttons for different roles that they can be in for each matter?

@AnnM9156 That is correct--it is just a field that records data regarding the application. You can, however, customize triggering for tasks based on the value in that field. I took a look at our docket, and our 3-month non-final OA response deadline has two flavors--one that is called "Respond to Non-Final Office Action - 3-month deadline" and the other that is called "Respond to Non-Final Office Action - 3-month deadline (Track One)." The "track one" version triggers when a non-final OA is received in a case that has Track One status specified, and the non-track one version triggers when a non-final OA is received in a case that does not have Track One status specified. Our 4-month OA deadline triggers when either of the 3-month deadlines closes as "missed."

The transient task solution wouldn't really do much--just email the recipients once when the note is updated. Fast forward a month later, and nobody will remember that they received that email, and might miss whatever is important.

Your pop-up slap-to-the-face approach would be much more effective at getting a user's attention.

Or maybe AppColl could just introduce a new FormField called "FirstNickname" that used the Nickname if present and the First if not.

Although your approach would be more flexible in case similar substitutions are needed in other cases.

Just upvoted your original idea, Sadiq.

Currently, the syntax for fields in form letters is somewhat inconsistent--some of it is very straightforward, whereas other parts are not.

Taking ClientRef as an example, the basic syntax is: {Matter.ClientRef}. This is fine--very intuitive.

If you want to add characters before or after the field value that only show up when there is data for that field, however, you have to specify each such character using +XXX, where XXX is the 3-digit ASCII code. Thus, if you want a form letter to say "Client Ref.: <Field Value>" but to completely omit this text if there is no client ref, the field changes to:

{+067+108+105+101+110+116+032+082+101+102+046+058Matter.ClientRef}

A person editing this form letter later will have no idea what the text is that these numbers represent. It makes it very difficult to revise form letters that have enhanced form fields like this. It also makes such form fields insanely long in some cases--the appended or prepended text codes will be be 4X as long as the actual text that they represent.

However, if you want to specify alternate text to display in place of the field if the field is empty/null, then the syntax is quite straightforward:

{!No Client Ref Specified!Matter.ClientRef}

You just enclose the alternate text in exclamation marks and put it immediately after the opening curly bracket. A person reviewing the field immediately knows what it will say if there is no data in the field.

I would like to suggest that AppColl update the syntax for form letter fields to also allow for text that is to be prepended and/or appended to a field value to be presented as either the +XXX format, as normal text, or as a mixture of the two. This seems like it would be relatively easy to implement, as you could have a routine that inspects the prepend/append clauses for non-+XXX values and then does a substitution to turn any such values into +XXX format for processing by AppColl's current algorithm.

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.

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?

@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.

Adding columns to a report is relatively easy--you get an interface with two listboxes--the left one lists all the fields that are not in the report, and the right one lists all the fields that are (in the order that those fields will appear from left to right). There are buttons to move a field from the left listbox to the right, and vice-versa.

HOWEVER, when you add a field to the listbox that lists the fields that are in the report, the newly added field is inserted ABOVE the currently selected field, and then the newly added field becomes the currently selected field. It should be inserted BELOW the currently selected field and then become the currently selected field.

In the current system, if you are going through a list of columns that you need to add to a report (and doing so in the order you want them to be in in the report), you need to, after adding each column, go back to the righthand listbox and click on the listbox entry one row down from the currently selected entry, and then go back to the lefthand listbox and select the next field to add. Or just add them all and then click a bunch more times to reorder the fields in the order you want them in.

The interface should be configured so that users can simply select the fields they want to add from the left side and add them in sequence, without needing to click in the righthand listbox at all.

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?