[Alexander Bautz]

Sorry, but that is not possible without using a PowerAutomate FLOW (SharePoint online only).

Alexander

[Alexander Bautz]

I’m glad you figured it out!

Alexander

[Alexander Bautz]

Hi,
Currently the only way to achieve this is to use the “Customizer function” option on a field in the “Build the table” section in the configuration.

The child table must be build using custom js / rest queries to the child list. You can find an example of a simple customizer function by clicking the link below the “Name of customizer function” field.

Alexander

[Alexander Bautz]

The only field types that have a delay when setting are lookup and people picker fields, but from the name of the field I assume this is a single line of text?

Alexander

[Alexander Bautz]

Hi,
You must not run this line:

$(“input[id$=diidIOSaveItem]:last”).click();

until after your custom sendMail is completed to ensure the form is not closed before your email is sent.

I don´t see any reason the txtRequestStatus field would not be set though – are you sure it is not overwritten by for example a FLOW? – do you see the value in the version log of the list item?

Alexander

[Alexander Bautz]

After updating DFFS it sometimes struggle to load, but it should resolve itself after approximately 15 minutes. If not, try going to the Application tab in the developer tools and click the “Clear site data” button (if you use Chrome or Edge).

Alexander

[Alexander Bautz]

Hi,
I assume that this is the classic DFFS.

You must create a rule that has the trigger “No trigger (must be triggered manually)” and then use Custom JS like this:

// No changes to this function
function detectChangesOnMultiLookup(arg){
    let currSelection = getFieldValue(arg.fin);
    setInterval(function(){
        let newVal = getFieldValue(arg.fin);
        if(newVal.toString() !== currSelection.toString()){
            currSelection = newVal;
            currSelection.forEach(function(v){
                if(v === arg.targetValue){
                    arg.callback();
                }
            });
        }
    },1000);
}

// Change fin, targetValue and TriggerMeOnLookupColumnChange
detectChangesOnMultiLookup({fin: "MultiLookup", targetValue: "Test item #3", callback: function(){
     spjs.dffs.triggerRule("TriggerMeOnLookupColumnChange")
}});

Change the fin (MultiLookup) with the internal name of your lookup field and the targetValue (Test item #3) with the target value. Change TriggerMeOnLookupColumnChange to match the rule friendly name of the rule you want to trigger.

Alexander

[Alexander Bautz]

I have seen this before. I think this is caused by a “stuck” definition from an old installation of Modern DFFS.

Try going to the site collection app-catalog and remove the Modern DFFS solution. Empty the recycle-bin to completely remove it and then re-upload it to the site collection app-catalog. Remember to check the “Make this solution available to all sites in the organization”. In a site collection app catalog the text is misleading – it will only apply inside the current site collection.

Alexander

[Alexander Bautz]

Hi,
Thanks for contributing Steve!

I usually set it up with the “Request type” choice field at the top of the form, and with a tabset below – with one tab for each request type.

Now I set up one rule for each of the request types and set show / hide the tabs so only the one matching the choice in request type is show, and set required / optional fields in those rules. Ensure you set any fields that might be set as required in another request type as optional in the one where this field is not visible.

When you create rules for fields that are shared between different request types, but the actions are not supposed to be the same, use the initial rules as the first condition in the rule using the “Run based on the result of another rule” – select the request-type-rule and set the toggle button to “Run if the rule is evaluated to TRUE”. Add the other condition in an “And” group as a new row. Now this new rule will only take effect if the primary rule is also true.

Hope this makes sense.

Alexander

[Alexander Bautz]

Hi,
If the rule in your DFFS form only triggers once to send the email, the retries when an email is undelivered is done on your email server and not in DFFS. I think that the only way to avoid this is to send one separate email to each of the recipients.

Alexander

[Alexander Bautz]

I’m glad it worked.

Alexander

[Alexander Bautz]

Try it something like the attached code. I have butchered your code a bit so you must edit it to match what you wanted to do after the child list item has been created. See comments in the code and let me know if you have any questions.

Alexander

Attachments:

1. dffs_PreSaveAction_Create_item_in_another_list.txt

[Alexander Bautz]

Hi,
Can you attach the relevant code as a txt-file? – please ensure you strip away any sensitive information.

Alexander

[Alexander Bautz]

I have looked through the old thread you referred to, and from what I can remember (and read) this issue is related to how SharePoint handles the suggestions-menu when it gets so many items that it causes a scrollbar. Somehow this causes the page to jump to the top on older SharePoint versions (it does not from what I can see in SharePoint Online).

Unfortunately I don’t have access to a on-prem SharePoint site anymore so I cannot reproduce this issue.

I think this post related to datepickers might be related so you can try to see if the same approach works (not sure as I’m unable to test it): https://sharepoint.stackexchange.com/questions/227471/sharepoint-date-picker-jumps-to-the-top-of-page-in-chrome-and-now-in-ie

Alexander

[Alexander Bautz]

Hi,
I cannot remember what caused this issue, but try looking at the Misc tab and uncheck the box Scroll to first visible form element in NewForm and EditForm if it is checked. See attached screenshot for details.

Let me know if that doesn’t make any difference.

Alexander

Attachments:

1. 

   Misc_ScrollToFirstVisible.png
   

[Author]

Posts