WELCOME TO THE COMMUNITY
find what you are looking for or ask a new question
Home > Forum > Latest posts

latest posts

In reply to: Daniel Krüger (Cosmo Consult)

Hi Andreia,

I sometimes face a situation, where I want to access the data via SQL and the values are not yet written / available for different reasons.
In these cases I move those "read" actions from the path to the OnEntry and everything works fine.

I'm not sure whether this would apply in this case though. The technical field would be set via a form rule and if you use the for each operator in the automation then you should be able to access the actual value. If it is set to true you could set a automation local parameter and decide whether to send a mail or not using this parameter after the for each operator.

The WFHistoryElements shouldn't use a count but should compare the HDT_DETID column of the previous version. In the worst case an old row get's deleted and a new one get's added which would result in the same count.

Best regards,
Daniel

Hi Daniel,

I was reading all the messages again and I saw I didn't wrote correctly what I want to achieve.
The idea is to alert another user that a new row was added. I'm not interested in getting the row information on the email, just check if there's a new line to inform the user that he/she needs to go in the instance.
I've trying to check the options under the history tables, I think the count for example will simply what I actually need but I'm not sure on how to create a condition where you compare new version with last version for that instance.

Did you implemented something like that in your developments?
Thank you

MVP

Hi everyone,

I have a process which updates the group members.
This is done in async mode because the synchronization takes a while.
I'm trying to prevent updates by moving the workflow to a step which checks whether the synchronization is finished.
As far as I found out so far a job get's added to the [UserSynchronizationQueueItems] of the current content database and it maybe get's deleted when the job is processed.
At least I thought so, because the job got deleted some time after the BPSGroupRelations in the config database had been updated. Unfortunately, the [CacheOrganizationStructureGroupRelations] in the content database still contains the old members for a few seconds. Which makes this check unreliable.
Does anyone have a better idea/understanding of the actual process?

Best regards,
Daniel

MVP
In reply to: Andreia Correia

Hi Daniel,

Because the actions do not run sequentially, do you think this works?
I had these kind of configurations in the past, but the field was always changed before the email was sent out (when webcon would evaluate to send the email, the flag was already false). I had to configure timeouts and never got this working properly.

What is your suggestion using the history? Compare the number of rows?
Thank you

Hi Andreia,

I sometimes face a situation, where I want to access the data via SQL and the values are not yet written / available for different reasons.
In these cases I move those "read" actions from the path to the OnEntry and everything works fine.

I'm not sure whether this would apply in this case though. The technical field would be set via a form rule and if you use the for each operator in the automation then you should be able to access the actual value. If it is set to true you could set a automation local parameter and decide whether to send a mail or not using this parameter after the for each operator.

The WFHistoryElements shouldn't use a count but should compare the HDT_DETID column of the previous version. In the worst case an old row get's deleted and a new one get's added which would result in the same count.

Best regards,
Daniel

MVP
In reply to: Paweł Tołoczko

in theory i did it :)
in practice ... i don't have access to dev now 9weekend)
but in webcon portal I did it :) and no errors so ... it should work

https://portal.webconbps.com/db/1/app/452/element/6829/form


---edit---
(I'm still learning...)
probably is not perfect and it could be tweaked .. but mechanic should be similar.
- invoke menu
menu start automation
automation send email
ad row change value of tech field
change of value tigers menu button

Hi,

I would implement it in another way. As far as I understand it, this would always set a technical field which in turn invokes the menu action. This would always save the instance, which may not be so good for the use experience.

I see two options, one with a technical field as suggested and one without.
- Technical field "Has been added"
- The field is defined in the item list.
- The form rule in the advanced configuration of the item list sets the field to true.
- An automation is executed in the OnSave trigger or a path.
- This automation checks whether the field is true for any row. Then you could decide whether to send a mail for all rows or for each row separately.
- At the end the automation sets the value to false for each row.

The alternative would compare the data of the item list against a previous version saved in WFHistoryElementDetails. This would work, but it may be more complex than using the technical field.

Best regards,
Daniel

in theory i did it :)
in practice ... i don't have access to dev now 9weekend)
but in webcon portal I did it :) and no errors so ... it should work

https://portal.webconbps.com/db/1/app/452/element/6829/form


---edit---
(I'm still learning...)
probably is not perfect and it could be tweaked .. but mechanic should be similar.
- invoke menu
menu start automation
automation send email
ad row change value of tech field
change of value tigers menu button