 | cooper collier 2/14/2018 6:35:28 PM I just today ran into an issue that probably was similar.
I partially solved the issue by using the new navigation actions. Not knowing your specific situation, I have no idea if they will help, but it you have not already looked at them, you may want to.
|
 | Kim 2/14/2018 6:51:36 PM I can't use navigate actions for this. My scenario is:
- Update record in table A
- Table A has a record change trigger that updates a record in table B
- Table B has a record change trigger with some actions <-- this trigger doesn't fire
This is by design, but if this is deliberate (and doesn't cause loops), you should be allowed to set that trigger on table B to 'allow cascade', so that it will fire.
The alternative is duplicating the actions from the trigger on table B, and add them to the trigger on table A, but updating records in another table is a lot harder this way (requires an outside trip through the API), and it quickly becomes unmanageable when you have three other tables all triggering this change in table B.
|
| cooper collier 2/14/2018 8:02:03 PM exactly. But. You can change the record change triggers into a custom button in table B
You can make the custom button hidden.
Now you update table A
Do your table A Actions.
the last action is the navigate: custom button.
This may or may not work for you. It partially worked for me.
I have a record in Table A
I was trying to create a linked record in table B.
At the same time make a note of it, in table C.
it worked perfectly and linked the note up with both table A and B.
But I wanted to cover the situation that there may not need to be a note.
So I tried putting a filter on the hidden button in table B, so it was available only if the Column Note in TAble B was not null.
But when I tried it, it caused an error message because the navigate action could not find the button.
My solution was to let it make blank notes in table C and I just filter them out of the user views.
So Navigate: custom button is not a perfect solution
Cascading Triggers is a great Suggestion, I promote it.
But maybe you can make it work like I did, until a perfect solution comes along.
|
| Kim 2/14/2018 8:18:55 PM How did you set up the 'navigate to custom button'?
|
| cooper collier 2/14/2018 9:08:53 PM this is a very quick and dirty example NO sound, I have a cold and cannot really talk. all the navigation actions are very new, teamdesk developers did a great job with them. But I am still learning the best uses of them. Essentially, they are used after you make a record change then you can do additional things to the new or changed record, and sometimes activating a button is a great thing to do. here is the video https://goo.gl/bhwoP1 |
| Kim 2/14/2018 9:21:12 PM Thank you very much for the video, it makes the concept very clear. However, although it's a great technique, it doesn't really address my cascade trigger in the right way, because navigating to that custom button is still an explicit action on the 'originating' record, and the power of the record change triggers is that you don't need to explicitly call them in every place.
|
| cooper collier 2/14/2018 9:53:49 PM You can use the navigation functions in a trigger.
I was just too lazy to do it.
As I mentioned I have not tested all the abilities of the navigation actions.
and from your other requests, you know more about the API than I do.
I may have to bug you for some advice on that side sometime.
ps.. you need to give me setup access to that color database if you want me to take a shot at the double record thing.
|
 | Philipp Matuschka (MMB) 2/15/2018 2:35:33 AM I actually didn't mean to promote that as I can see the difficulty with the potential Loop.
What I did want to do was post a comment:
I found that Time Dependent triggers "almost" do this. So if I have time dependent triggers A and B and the result of trigger A should cause B to run, then at best it will run as part of the same "trigger processing batch" (no idea if that is the right terminology). At worst trigger B will run approx. 5 minutes later.
In certain instances, and I cannot work out the common denominator, even that doesn't work. So for those cases I monitor the results for the first few days and if I find there is a problem, I run a nightly trigger with exactly the same actions and a filter to make sure it isn't duplicating and thus everything is tidy the next morning.
|
 | calvin peters 2/15/2018 5:20:53 AM I've worked around this in the past using REST API
As long as you dont set the " workflow=0 " at the end of your REST URL then all triggers are fired on updates performed by the API. Cascading changes across tables inside an application are immediate Looping is a concern to consider as it can be easy to forget what cascades across a large application.
It has also been a workaround for updating records that require higher level record access so that tables users don't have access to can be updated as if the admin made the change.
The only drawback I have experienced is in some instances the cascading data load across the application can create a noticable time lag in performance as ALL of the cascading updates seem to fire sequentially rather than concurrently so the time per action can add up if the actions are numerous. There are other considerations that can cause slow down when cascading changes. It can get pretty hairy in a hurry if youi don't plan it out properly.
As a result I have returned some of them to Timed Triggers to reduce those slow downs at a user level. Delayed updates are sometimes prefered over staring at an hourglass spinning on a screen. And timed triggers generally cycle every 3 minutes in my experience so the delay is minimal.
Good luck
|
 | Philipp (JFDI/Teamdesk) 2/19/2018 3:43:13 AM Hi Cooper
I was trying out some stuff based on your comment of 2/14/2018 8:02:03 PM. The difficulty I am having is how does the system know which record in Table B to update.
So in my case,
Table A--> User Settings
Whenever a new record is created by a User in Table A, I want a column in the User Settings table updated with the new Record ID from Table A, as this now the data the User should be working on.
Currently I have two choices
1) Time Dependent trigger in User Settings which detects that the user created a new record in Table A and updates accordingly --> OK, but the time delay can be annoying and/or confusing for the User
2) The User has to hit an UPDATE (or similar) button on his own User Settings record. At least it removes the time delay, but it is still an annoying additional step for the User
So I was reading your stuff above and thought that as the last action on a Record Change trigger after creating the record in Table A, I would navigate to a hidden button in User Settings, (naively) thinking that the system would recognise the relationship and "know" that there is only one record I could possibly mean. But nothing happened.
So my question is: how do you instruct the system which record in Table B (in my case User Settings) is it that you want the Button to apply to?
|
| cooper collier 2/19/2018 8:44:40 AM You can email me directly as this is probably getting beyond the initial question.
But since you asked here.. this is maybe the answer...
I think you are asking for how to do what I call "double-linking"
Start in Table A Create new record in table B, and TAble C you want Table C to be linked to Table B
(without user input)
In short, teamdesk does not natively do this.
But you can trick it.
Teamdesk does not care what is in the ID field, just so long as its unique.
THE ID numbers do not need to be sequential either.
What I do is make a hidden column called [Random ID], in table A
When I press the button or make a trigger the first thing to do it set RandomID
[randomID]="INV"&Format([Date Created],"s")&Random()
I always use a formula with a timestamp and random. making it nearly impossible for 2 people an get an identical ID.
Then I use this ID for the ID of the first table new record
Table B [ID] = [RandomID]
Populate the reference column in the 2cnd table new record
Table C [Referece to table B]=[RandomID]
There are a few considerations
Always make sure the Date is part of the random ID that way the previously used ID will always be in the past.
If you have a database with lots of users and its a popular function, I would consider making a double random number Rnd()&Rnd()
I am not 100% sure what would happen if a second person triggers the process again in the interval between creating the record in table B and table C. I "think" it will still work as expected, but I have not been able to actually make this happen. The process is so fast (close to instantly) that the odds of it happening are tiny.
|
| Philipp Matuschka (MMB) 2/28/2018 9:34:10 AM @Staff: Is there any way to convert an Idea to a Forum entry as I think that is what this has become.
@Cooper: Thanks for that, but it is not quite what I am trying to solve. In my case I only have a table A and a Table B. Table B is in fact User Settings. Whenever a User creates a new Record in Table A, I immediately want a column in Table B (User Settings) updated with the Record ID just created in Table A.
Currently I do this with a time dependent trigger on User Settings which triggers on Max Date Modified from Table A, finds the most recent record added to Table A by the User and as a result updates the required column in User Settings. This works, but the time delay is annoying.
What I want is, that when the record is added to Table A, I can use a Record Change Trigger to update the said column in the record for the User in User Settings
|
| Kim 2/28/2018 9:52:26 AM Well, I actually don't want this to turn into a Forum discussion. Feel free to open a new one to discuss workarounds. This is a very clearly outlined Feature Requests: 'Allow record change triggers to cascade'.
|
| Philipp Matuschka (MMB) 2/28/2018 9:55:37 AM Sorry Kim, I forgot that's how it started. I was thinking of the bit going on between Cooper and myself
|
| cooper collier 2/28/2018 10:29:20 AM I think I see, you wish to update an existing record in TABLE B from TABLE A.
I have yet to find a way to do this. I have run into this before, and the best I could do was make another table and do a many many to TABLE B and use a summary to display the data.
I then make a new record in the TABLE C just for the data I want.
It is clunky, but the best I have ever found.
Sorry
|
| Kim 2/28/2018 10:34:11 AM @Phillip reading back on your use case, I think you are better of with another Idea: https://teamdesk.crmdesk.com/answer.aspx?aid=27250. Because this Idea wouldn't help your use case. This one is for this use case: 'When I have a record created or updated through an _action_, that create/update doesn't trigger any record change triggers'. |
| Philipp Matuschka (MMB) 2/28/2018 10:40:46 AM Thanks Cooper and Tim. I think I am going to bow out of this discussion for now and look to try to solve it via the API. Thanks for all your help to date
|
| Philipp Matuschka (MMB) 2/28/2018 10:40:58 AM Kim, not Tim
|
| calvin peters 2/28/2018 11:43:37 AM @kim
So, (if I understand the above properly....and maybe I don't) what you are trying to do is possible through the REST API using <Call URL> action.
It allows you to set actions to trigger in table B which have been updated by a change in table A and all of the triggers you have set to fire with the change in value on table B will be executed.
The Call URL function will circumvent the restrictions built into the Update Record and Create Record Functions setup in td as long as the URL is setup without the workflow parameter set to 0. Use UPSERT method with no workflow. And for what it's worth, the build out is not very much more work. You will likely notice how similar the structure is to the built-in funtions provided.
1) [column 1] in table A is updated and executes Record Change Trigger or a Custom Button is clicked
2)Record Change Trigger / Custom Button executes a Call URL action to do UPSERT Method to Table B
3)Record in Table B [column 1.0] changes value and executes Record Change Trigger as required. and if necessary THAT Record Change Trigger can execute another Call URL to further cascade update in a third table or even back to the original table as long as it is not back to the record that started the cascade.
Perhaps I don't fully comprehend the problem but I think this is what you need to accomplish.
As for User Settings and updating them, this type of Call URL allows for changing adding and updating User Settings in the td users. So End Users can add, delete and update their own users without having access to the setup functions and application structure directly.
|
| Kim 2/28/2018 1:45:09 PM @calvin peters I appreciate you taking the time to describe this method in detail. I am aware of the possibility, and it's actually what I'm using in a number of cases. However, it's still a workaround (having to go outside and back in).
Plus, it has its own set of problems. For one, our REST API is locked down to tokens only. Plus, I can't easily 'impersonate' the actual user triggering the first action in the first table this way, even with user/pass enabled on the REST API. The same goes for the other proposed workaround, using time-based trigger on the second table based on a aggregate lookup selection on Date Created/Modified. These always run as db owner, which can be very undesirable.
Again, I do appreciate you taking the time to describe a possible workaround, but this Idea is created to make this type of _controlled_ cascading possible out of the box, without workarounds.
|
| Philipp Matuschka (MMB) 3/8/2018 10:10:15 AM @Calvin: Would you have an example of the code used in the Call URL referred to you in your last post
|
| calvin peters 3/8/2018 10:38:31 AM @philipp
Email me direct and I'll be able to give you a hand if you need.
No problem
calvin.peters1@gmail.com
|
 | basenine 5/23/2019 5:23:48 AM @all
I have just discovered that in the Workflow Actions, there is a new function called "Record(s) to update"....(wasn't there last year!)
This is gold and has opened up an enormous opportunity to simplify the many workarounds we all create.
It works with two tables that are directly related (i.e. from a Reference column)
Example:
I have a Table B that I reference to Table A.
In editing a record in Table B, I say that I want to make the item in Table A a different type (From "empty" to "outgoing")...the type was a drop list of selectable fields and it needs to stay that way (otherwise I would have used a combination of Summary and Formula columns)
I also needed to update other fields in the record from Table A...any other way than this new way would have resulted in a partial rebuild (probably at my expense too)
This new Workflow Action solves all this and allows for updating related records.
To me, some of the comments here would be addressed by this. I literally stumbled across it today and as it happened, it got me out of a jam.
|
