You are viewing limited content. For full access, please sign in.

Question

Question

Feature Request: Dynamic field based off of template

asked on April 1, 2015 Show version history


It would be great if a dynamic field could filter its possibilities based off of the selected template.

For example, we have departmental templates, which have a shared list field (Document Type) that should have different possibilities depending on the template that is applied to the document. Some departments have more than one template, and each template should have different possibilities for the Document Type field.

By dynamically filtering the possibilities based off of the template as opposed to another field, it allows the end users to have the appropriate selections without having to worry about manually entering the value in a separate field in order to filter the Document Type list.

Thanks!

5 0

Replies

replied on April 2, 2015

I second this request, for the same reason. It would also be nice to be able to retrieve the name of the current template in workflow.  

Off the top of my head, you might be able to use workaround to simulate what you want 

For each template you have, create a list field with one default value that identifies the template.

Add each field to its respective template. Now when that template is assigned you automatically have a hidden field that defaults to the name of the template (just don't give anyone rights to see it). 

Setup dynamic field to key off the template field.

1 0
replied on April 2, 2015

Barry - 

Maybe I'm misunderstanding your statement, but you can currently retrieve the template name of an entry in workflow - just use a Find Entry activity, and one of the Additional Properties available is Template Name.

0 0
replied on April 2, 2015

OK -  maybe its not available in 9.0?  I don't see Additional Properties listed for the Find Entry activity. Or I may be looking in the wrong place...

0 0
replied on April 2, 2015

I believe it was added in 9.1

0 0
replied on April 2, 2015

Barry,

That is actually a really cool idea. Right now the way we are accomplishing it is similar in that it adds a lot of fields -- we have fields for "Document Type (xx)" where xx is the 2-character department identifier. The method you suggested would allow us to provide a cleaner look to the end user though, so we may check out switching to that strategy.

Thanks Barry.

1 0
replied on January 11, 2016

I second the initial posters feature request for "dynamic field could filter its possibilities based off of the selected template

0 0
replied on January 26, 2016 Show version history

I have set this up with a list field (Template Admin) to identify the template then do a dynamic lookup from that field to show a specific list of Document Categories (Document Category).  This part works fine.

 

My issue is that when I set the security on the list field (Template Admin) so the end user can only read it (don't want them changing it), any existing document with this template (Administration) chosen cannot be changed by the end user.  If a new document is brought in by the end user, they can choose any template and all works.  But after a doc is in LF with template chosen it cannot be changed by the end user.

Is there a way around this?  Something I am missing?  The only way I can get it to work is to give the end user the ability to change the field "Template Admin" at the botttom.    Template/field security below:

Template opened by the end user: ("Document Category" dynamic drop down still works)

I am using LF version 10.

0 0
replied on January 26, 2016

Changing the template may remove fields, and removing a field would be considered modifying it, so this is the expected behavior and is documented in the help files.

Are you actually needing users to be able to modify the template in this case but not the field, or were you just wondering why it was behaving this way?

0 0
replied on January 27, 2016

Thanks for responding.  Yes I am needing the users to be able to change templates but not the field named "Template Admin" as this one is defaulted so the lookup for "Document Category" can show appropriate results.

 

I have other templates and they have their own "Template Admin" field but if the template is for Human Resources that field would be "Template Human Resources" as to provide the correct lookup for HR.

0 0
replied on January 27, 2016

It sounds to me like there would be other ways to resolve your issue, but I'm a little confused by the process.

What is the flow that you want your users to follow? How is this default value currently being set? When would users need to change the template, and would that need to change this field's value, too?

0 0
replied on January 27, 2016

Here is a video for convenience.  Opened directly in Chrome for me :-)

https://www.cubbyusercontent.com/pl/Instant+Meeting+2016-01-27.webm/_7febf51cfa654f5097161b907cc3edc5

Flow would be:

1.  User assigns template

2.  Field "Template Admin" is defaulted to a value that is in the DB

3.  User selects field "Document Category" and sees a list based on the the lookup ("Template Admin" value is in the database and returns a list matching)  This is so the user only sees a list that is appropriate to the overall LF template called "Administration".  

4.  User saves doc, but then realizes that it is the wrong overall LF template and needs to change.   They cannot because each overall LF template has the read only field "Template Admin, or Template HR or Template Finance" depending on the overall LF template picked (Administration, Human Resources or Finance) respectively.

I could do a video if that would be easier.

My use case is that I am using the field "Document Category" as a routed folder name later on that is based on the Province's recommended record series folder structure in Records Management.

I guess if this is not going to work I will have to not use a db lookup (done per LF Template would work).   And have to use a different field with the relevant list.  The problem is that now work flow is going to have to look for multiple fields to find that info.  Where before it was just looking at "Document Category" 

0 0
replied on January 27, 2016

Thanks for the additional information. When we're making decisions on features, it's always helpful to know how people are currently using them.

Since the value depends on what the user has selected for the template already, it seems like you're already trusting them to determine the document type, so leaving the field editable isn't changing much about what the user can do.

If you are worried about consistency, you could create a workflow to regularly check for and correct/tag for correction documents where the field value does not correspond correctly to the template name.

2 0
replied on January 28, 2016

Thanks for the info.

In the end I have removed the db lookup and created a "Doc Category" field specific to each template that lists the categories for that template.  Was more work in the workflow to get it to work but works great.  There is no need now for locking down a field.

Having a db lookup based on template chosen would be great in the future.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.