When a relation is set to auto-link, the automation to “add entity” is removed from the automation list. While this makes sense, it would be nice to be able to create and manually add the field that would then link it to the triggering entity. Right now it needs an extra relation field, just to create this item on the trigger…
It would need to probably have a different name “Create” instead of “Add”, as it does not get linked by default, but it would be nice to have here.
How would this work if the matching field value cannot be set, e.g. matching on a formula field value?
No idea, but maybe the action can have a warning: “Warning: This is an auto-linked relation, this action can not ensure linking to the triggering entity”
Seems to me a narrow version of this topic:
Indeed!
While I understand why its only to the ones they are related to, then removing the functionality for auto-linked relations is unfortunate.
The functionality for auto-linked relations was not ‘removed’, it never existed.
Auto-linked relations are somewhat like formula fields or lookups (read-only) and we don’t allow automation actions to create items for these either
I see.
Do automations for lookups and formulas exist? Update the items in lookup?
Auto-linked relations are a bit of an in between, I can understand that, but for this situation of automations, I would lean towards allowing creation.
An example:
A button that creates a new Supplier from New Supplier (2 different database due to form view filtering limitations)
Ideally I want the Supplier and the New Supplier to be auto-linked based on the IBAN (that way people can see that this supplier already exists and won’t press the button), but then the button to create the supplier can’t be used. So I must create two relations, one autolinked, and one for the automation to work.
It sounds like autorelations are a workaround, so we should address the limitations (whatever they may be).
Perhaps you need forms to support ‘upsert’ (update if existing, insert if not)…
The idea of it to see any duplicates before creating a new one. If it already exists, the user can press the “Decline” button. If it doesn’t the user presses the “Accept” button and it creates a new Supplier in the Supplier DB.
Sounds exactly like a case for ‘Create or update’, with the conflict option of ‘skip update’.
If this was supported in Form view, wouldn’t that be all you need?
I’m a bit confused as to how, I will explain the full flow.
- When creating a Source Document, user must select a supplier. This can not be filtered, this is the main missing filter, this needs be filtered because we suppliers to have “Needs Reviewal”, and “Active” status.
- Workaround: 2 DBs. One for “New Supplier” (Needs reviewal) and one for “Supplier”, which is shown in the form. When someone submits a new supplier, it goes to “New Supplier” database, and then someone will review, and press an “Approve” button which will then create a record in the “Supplier” database with the same fields. The “New Supplier” form will be public for suppliers to fill out. So there is a chance they are already in the system, and I want the users to see that, hence the autolinking.
Let me know if this makes sense!
Create or update could be useful in some places here, yes. But not in the fact of seeing if there are duplicates and making an informed decision on what to do.
What is the context for creating a Source Document?
An internal form view? A table view?
Where is the need for filtering missing?
Basically, the use case seems to be predicated on being a workaround method. If we can avoid the need for w workaround, the use case disappears
Internal form view, exactly.
In this case, yes, but there may be other scenarios where you need an auto-link to see if a duplicate already exists, then a button to create an entity with that nature if not.
To be honest, after all of this I got the conclusion that the extra field for automations isn’t the end of the world as it attributes where the entity came from. More data is always better.
Seeing as this has zero votes, I think this can be closed. My mind has been changed!
Well, that’s kind of my point. If the button uses a ‘create or update’ mechanism (with skip if already exists) then you don’t need auto-linking to check if a duplicate exists - the button would just take care of this
Yes, but what if I don’t want it to be done automatically? I want to see if something exists, compare the details, and decide.
Maybe the new one is more up to date so I want to update the old, or maybe the new one is more up to date, except for one place where the email is spelled incorrectly.
Yes, upsert would make things automatic, but that is not always desirable, is what I’m trying to say.
It seems like the goalposts are moving 
Originally, it was about being able to link to an existing record, or if one doesn’t exist, create a new one:
and now it’s about being able to review an existing record, assess if the information is up to date, and if not, update it:
…and it sounds like you were hoping that the ‘create entity’ internal form view would be able to handle both of these actions simultaneously, which is a big ask.
To be clear, I am not trying to dissuade you from providing examples of what you are trying to achieve, and why it’s not currently possible, I’m just trying to drill down on root cause(s), so that we can identify specific needs (which other community users might want to weigh in on).
I worry that we’re wandering around a few different issues in this thread.
Haha, it was implied.
I don’t expect it do anything automatically. This specific need is when you want it to be a manual process. To see the existing ones, and then decide what to do.
To be clear, this has nothing to do with the form view’s create functionality. I’m not sure where this was understood.
“New Supplier” has a specific form for them (public), and new Source Documents have internal forms, where “Supplier” is linked, not created.
errr…
I will admit, I am now completely lost, and I think I am not helping by asking questions. Maybe someone else in the community understands what’s going on 