Column to store 100 Phone Numbers

This is a good idea. Do not store multiple values in a single field.

For the design of the data model, I suggest to follow these guidelines

docs.appian.com/.../data-modeling-with-appian-records.html

Hi Stefan,
Thanks for your response, The above guideline will lead us to redesign the whole process.

Currently we are using the CDT for target with below structure.

{
'type!{urn:com:appian:types:TEST}TEST_Target'(

targetID:" ",

'orderID': 1,

'targets': "123;3422;23443",

'searchDate': fn!datetime(2023, 2, 18, 0, 0, 0, 0)

)
}

How can we redesign this so that 'targets' column could be array of cdt itself like as shown below.

{

'type!{urn:com:appian:types:TEST}TEST_Target'(

targetID:" ",

'orderID': 1,

'targets': {

'type!{urn:com:appian:types:TEST}Test_RelatedTargets'( targetID:' ', 'Target': "123" ),

'type!{urn:com:appian:types:TEST}Test_RelatedTargets'( targetID:' ', 'Target': "3422" ),

'type!{urn:com:appian:types:TEST}Test_RelatedTargets'( targetID:' ', 'Target': "23443" )

}

'searchDate': fn!datetime(2023, 2, 18, 0, 0, 0, 0)

)

}

Appian Records do not support nesting. Create two separate records and relate them.

Appian Records do not support nesting. Create two separate records and relate them.

For relating two records I think we might have to use the Sync Enabled record, which have its own issue with data availability on a immediate basis.

Is this possible to get this implemented with Nested CDT ?,

If yes then how can we map the targetID of the TEST_Target to targetID of the Test_RelatedTargets so that during write2DataStoreEntity the generated ids gets mapped to the nested cdt.

Out of curiosity, what do you mean with "own issue with data availability on a immediate basis"?

So, nested CDTs in a datastore will manage that automatically, if you set up the nesting relationship correctly. Just create the fields in the parent and child CDTs as required and for targets, select the child CDT data type as a list. Appian will then add the required fields and/or tables to manage that relationship.

With "own issue with data availability on a immediate basis" I mean the record will not be updated immediately until the Record get synced. And we cant sync the record every time we run the process.

User will keep on seeing the un-updated data for the time until record get synced.


I have done the implementation as shown below, Though I have used one 2 many relationship in the nested cdt, the data is not getting populated in the DB as expected.

Test_RelatedTarget CDT

TEST_Target CDT

where mapping is as below

The way I'm framing the cdt on the UI is As shown below,

But when we are writing the data in DB, all the targets are getting clubbed into 1 column itself.

Hi,

I see an issue with your nesting configuration. The DB column is not matching the name that you provided in nested configuration.

Try with this configuration

hopefully this will work for you

You mentioned that the data doesn't show until it gets synced, but as long as you are updating data through nodes like Write to Data Store Entity or Write Records, those nodes also immediately sync the data.

GauravSingh said:

I mean the record will not be updated immediately until the Record get synced. And we cant sync the record every time we run the process.

As Peter already pointed out, but just to reiterate very specifically, this is not true.

Hi Naresh,

Thanks for your response, its just I have changed the Column Name in the mapping to 'relatedtargetid' instead of relatedTargetId, and it seems to be working.

Will test the flow once and let you know if some unexpected behavior occurs.

Thanks,

Gaurav Singh

Hi Peter,

Let me try this again, when we did that in Appian v22.2 we faced such challenges.

Thanks,
Gaurav Singh

There should not be any differences in this behavior in 22.2, but please comment here if you are having issues.

Hi Peter,

Below thread is specifically what I've faced as well.

https://community.appian.com/discussions/f/data/27611/data-written-by-write-to-data-store-entity-not-getting-synced-in-record-type