There's really not enough detail to provide you with much help.
"Allow creation..." is a check box that does not entail big risks for your data in any scenario that I can imagine. The worst you might get is an extra blank row in a portal where you don't want it--the bottom "add" row used to add new related records directly in the portal. You do want to be careful not to remove this optio in an existing relationship without carefull analysis and testing. This feature may be required for a data entry portal or it can be needed for certain scripts that use the relationship to create new related records.
"Delete..." is the check box to select with great care. If "delete" is selected in an occurence of Table B relationship between table A and Table B. Deleting a Table A record anywhere in your database will invoke that delete setting and delete any related records in Table B. You can even get a "cascade" of deletes where deleting a record in one table deletes records in a second which then deltes records in a third...
I suggest that you do what you can to organize your relationship graph to make it easy to see what occurrences refer to a common data source table. I try to color code mine so that all with the same source table are the same color. It can also be helpful to use a naming convention where the name of the data source table is part of the occurrence name, but in ALL CAPS to help identify the source table.
Working towards an Anchor Buoy format can also be helpful.
And FileMaker Advanced will be very helpful for you in being able to create a database design report. Not only can doing text searches on this report help you track down specific details such as every script that has a delete reocrds step, there are third party tools that can take a database design report and help you analyze the design.
And as in any development endeavor, test your changes frequently and make lots and lots of backup copies when developing so that you can revert to an older copy if you find that a particular change didn't work out like you expected: Saving Sequential Back Ups During Development
Forgot to say thanks,
Have followed one of your designs very closely.
I just need to slow down and follow the accounting trail via many tests and many DB backups.