Need a TRUE "App Reference" Field
The current fields called "App Reference" fields are really_ "App Item Reference"_ fields. I need a true App Reference field so I can build a Bot configuration workspace that allows admin users to specify which Apps they want the Bot to interact with. I can currently get the admin users to enter the App's URL but that is harder for the users to figure out and it would be much more elegant to allow the users to select the available Apps from the specified Workspaces.
-
@Christian - My use-case is API related, and it would be useful for people building solutions using the API for other users because many uses of the API would need to reference which Apps they should interact with. It makes great sense that an add-on solution for Podio that uses the API would have a workspace and Apps that allow the admin users to configure the add-on solutions.
Further, a TRUE App Reference field could enable an admin user to create Widgets showing the Apps that users need to use for different purposes. It would be the beginning of you being able to add true workflow into Podio.
-
One vote up for adding app field reference or letting us filter the data based on a specific field in the referenced app.
@ Christian - I think it depends a lot on way you've built your apps and the way you want them to work together.
I'm also looking for this exact same feature, for a HRM app where I want to reference the different tasks of each job, in projects. It does seem like a lot would benefit from it, based on this thread:
-
Hi guys. I think there is some confusion here. Mike wants a reference field that points to an app, not a reference field that points to an app field.
Your problem Anders is fairly common for advanced users of Podio, and something we internally would love also. However it is far from simple to implement for two reasons:
a) It is quite hard to make a user interface for this that usable for both novice users and advanced users. The options become very overwhelming when you make it possible to filter on related apps also.
b) This is not easy to expose using declarative filtering in the API. If we were to do this we would most likely need to make a query language (or adapt one), which is no small task.I can fully understand the need for related apps filtering and I think we will do this in 2013, but the "true" app reference field does not make much sense for me outside an extremely limited use case.
-
Hi Christian, Thanks for the quick answer. I appreciate it! I can see that I misunderstood the question then. Sorry about that. I hope though that you''ll be able to implement the refer to app field feature. Not being able to reference app fields seems quite a bit counter intuitive. It will really make Podio apps much more flexible and drastically reduce and simplify the number of apps necessary to build up workflows, if this feature could be added.
Keep up the great work!
-
Hi Anders
There still seems to be some confusion. Linking to a specific field in an app doesn't make much sense either. I truly think there is nothing wrong with our basic concept of referencing. It works exactly like foreign keys in databases, and that have stood the test of time.
What you cannot currently do is _filter_ by other fields on the referenced app, but that is not a problem with the reference itself, but the filtering capabilities.
-
Hi Christian,
Please clarify.
I don't see why it wouldn't make sense, and maybe this discussion should be brought to:
https://help.podio.com/entries/21683251-app-references
as there are so many people with this request.
It would seem quite natural being able to pick exactly which field in an app you want to get data from instead of being limited to getting data from the topmost field only. Let me give an example: If you have an app with 10 fields, why should you be forced to only refer to the topmost field, when you have data in 3 fields in the specific app, that you want to refer to from different apps. To accomplish this as it works now, you would need to split each of these fields into seperate apps, just to be able to refer to the fields, which would results in a mess of small single field apps.
For instance I have a Jobs app that has Job Descriptions for employees, along with other things. Here for instance I have two fields that I want to refer to in multiple apps:
See - http://cl.ly/image/0F3u3v2g3D3B
Job Title (which I want to refer to from an employee app + from a Job Application app/webform)
Job (which I want to refer to from a task tracking app).
Here, it would be very natural to be able to keep both the Job Title and the Job field in the same app. However due to this limitation (lack of app field references) I have to make a seperate app, with just a single reference Job field, even though they both belong in the Jobs app.
-
I am fully aware of all the requests, but they are misguided none the less. There is a conception that the reference is to the first field in the app. This is not true. The title of an item is generated from the first field in the app with a value. This title is used in countless places in the system to have a single line label to relate to the items. This however does not mean that the reference is just to the title.
One of the key UX issues we are currently trying to solve is making those references better displayed to make it clearer that the reference is to the item as a whole. In addition I am also considering making it possible to select multiple fields to generate the title from.
For your specific example I am unsure what hides behind the label "Job". I assume this is the job function. If you are trying to assign tasks to a job function, for which there could be many with different titles, then the function should be in a separate app.
-
Hi Christian,
Just to follow up. As I understand you, what you're referring to is more the technical approach to linking, that you don't think makes sense. For me personally, it's not in any way important how it's done technically, but more that it becomes possible to refer to a specific field (in whatever way it may be done technically). Because currently, it is very limiting, as to a certain degree you can't centralize as much related information as you want (in this case relating to a Job/task).
I hope my example shows that - and that's one of the reasons why me and others have brought forward this feature request. Crossing my fingers for some kind of solution to this issue, in the future :)
All the best
Anders
-
Hi Christian,
"There is a conception that the reference is to the first field in the app. This is not true." - I didn't realize that. For me that seems counter-intuitive and confusing.
"For your specific example I am unsure what hides behind the label "Job". I assume this is the job function." - Exactly. It's the job function, and I want to be able to reference this job function from the Task Tracking app.
"If you are trying to assign tasks to a job function, for which there could be many with different titles, then the function should be in a separate app." - This is exactly the problem. It means that you can't centralize related information in the one single app where it would belong, but that you have to make extra apps, for each field you want to refer to, just to work around it. If I have 5 fields I want to refer to I have to create 4 new apps single field apps, each with one of those fields. Not really a useful solution.
If my example still doesn't make, maybe some other people could add some input, to clarify the problem and the reasons for finding a solution to it.
Anders
-
So say we somehow made the app field reference you request, what would it mean to link to this job function field, that I assume is a category or text field? If you were to model a relational database for this, what would it look like? If you are trying to create a list of job functions, then that truly should be an app. It might seem cumbersome to start with, but it is the only proper way to model this in Podio, a database or in any other system.
If you are indeed assigning tasks to job functions rather than job titles, then these needs to be defined separately as you cannot define them at the same level. One could invision a sort of "shared" field that could be reused in many apps, but that really is just a special case of the solution I propose. It has the added advantage that a) your list of functions are much more dynamic and b) you can add additional fields to add additional information about the job function that is common for each job title.
I have a hard time imagining that you have 4 other field that have the same problem, so I cannot comment on those unless you get a lot more concrete.
-
Hey Anders - as Christian Mentions I think you and the OP are after different things.
It seems that you, like me, want to be able to filter a referenced app item list based off some other attribute of the item (say, a category) - which is what (If I read the thread correctly) Christian alluded that they are working on for 2013 (this would allow you to only show people (item) with the job (category) of 'developer' in an app space reference.
But if you also want to go further and display a specific field from within an app item (say, pulling an employee's (item) Job Role (field) to display from the app reference then that does become a bit more niche, and I can't say it is something I have found a use for yet.
-
@ Eddie
"It seems that you, like me, want to be able to filter a referenced app item list based off some other attribute of the item (say, a category) - which is what (If I read the thread correctly) Christian alluded that they are working on for 2013 (this would allow you to only show people (item) with the job (category) of 'developer' in an app space reference." - That would definitely be extremely useful, but that's not what I'm after here.
"But if you also want to go further and display a specific field from within an app item (say, pulling an employee's (item) Job Role (field) to display from the app reference then that does become a bit more niche, and I can't say it is something I have found a use for yet." - That's what I'm looking for.
I think I need to make an example using the apps I have built, for this to make sense, as I can't imagine this can be niche. I'm not sure I have communicated it clearly enough.
-
"So say we somehow made the app field reference you request, what would it mean to link to this job function field, that I assume is a category or text field? " - Yes, typically a category field, but any type of field preferably.
"If you were to model a relational database for this, what would it look like? If you are trying to create a list of job functions, then that truly should be an app. It might seem cumbersome to start with, but it is the only proper way to model this in Podio, a database or in any other system. " - I think I need to make a visualized example to explain my scenario in the best possible way.
"If you are indeed assigning tasks to job functions rather than job titles, then these needs to be defined separately as you cannot define them at the same level." - I'm assigning different types of tasks to job functions, because a job function is responsible for many kinds of tasks.
""One could invision a sort of "shared" field that could be reused in many apps, but that really is just a special case of the solution I propose. It has the added advantage that a) your list of functions are much more dynamic and b) you can add additional fields to add additional information about the job function that is common for each job title."" - This could also be interesting.
"I have a hard time imagining that you have 4 other field that have the same problem, so I cannot comment on those unless you get a lot more concrete." - The 5 fields I mentioned was an example to show why I don't think your suggested solution works. I don't have that many fields I want to reference yet. Another example - maybe I'm a perfectionist, but when referencing a Task Type (in a task tracking app), I would like the Task Type to be "Script Writing" (the "job") and not "Script Writer" (The "Job Title"). That's another example why I would like to have both of these fields in the same app (the "Jobs" app), and then reference each of these fields from other apps.
I will have to make a visual example.
P.S. My purpose of my original post was only to make a quick feature request. I thought it was simple, but I had no idea it would turn into this long a discussion. So I'll need to get back on this when I have time, and when I actually work on the Podio apps.
I appreciate all the input!
All the best
Anders
-
Christian,
I am not sure if I can add to this or not - my issue is that the title of the referenced app the only piece of information that prints out when you export to excel (unlike the contacts reference where all the fields print out). So I need relevant fields from the referenced app to print out in an excel export (If I can do this without selecting a specific field in an app to reference then that would be fine also).
Kirsty
-
My point is the discussion of the app and its use, rather than referencing individual items within it. The reference field for the app item does not give the viewer a full understanding of what that app contains and how it can be used.
I currently reference an entire app by using its URL in a website field (it would be much tidier in a dedicated field). I use this on job description cards for each of our intern roles, as they may have access to a workspace but only use a few apps, while other interns use different apps.
I do this often in preparing for meetings:
To show folks in an upcoming meeting where the info they want is stored.
To show them a new app
To ask whether the app, or its redesign, meets their needs
To suggest that information they have been putting in app A is better off in app B.
To introduce new interns (we have many short-term interns) to one or two apps that we will be discussing in a meeting.
Inviting a new person to an entire workspace often results in confusion, and requires documentation on how we expect them to use it. I find it very useful to review one app in the workspace at a time, in meetings, thus providing (in the meeting agenda and minutes) a detailed and familiar app reference, tailored to the individual, their use, their perception, and their questions. Having a reference field in the meeting precludes their having to search for it in preparation for the meeting.
Please sign in to leave a comment.
Comments
17 comments